From owner-ietf-calendar@mail.imc.org Mon Nov 3 14:24:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15814 for ; Mon, 3 Nov 2003 14:24:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JCRkT046722 for ; Mon, 3 Nov 2003 11:12:27 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3JCR1K046721 for ietf-calendar-bks; Mon, 3 Nov 2003 11:12:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JCQkT046705 for ; Mon, 3 Nov 2003 11:12:26 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA2DF29.2040803@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 3 Nov 2003 14:11:16 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/03/2003 02:12:12 PM, Serialize complete at 11/03/2003 02:12:12 PM Content-Type: multipart/alternative; boundary="=_alternative 0069193C85256DD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069193C85256DD3_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/31/2003 05:16:09 PM: > Better yet, an example of when MODIFY breaks. > > Take TWO VLARMS that are identical in one component. > Withou a unique identifier - you can not uniquly identify the 2nd > instance. I claim that this is a non-sensical / practical case to use. (Plus its the only one I could think of too.) We dont allow multiple VDAYLIGHTs or VSTANDARDs with the exact same data to be a single VTIMEZONE and yet consider the defintions to be different. We do not allow 2 VEVENTs in the same calendar to have the exact same set of properties and subcomponents yet call them different VEVENTs. We even said in iCalendar that repeat instances for the same date/time are to be treated a single instance. So why would we now invent this different consideration for VALARMs? Taking a practical look I have to chuckle at the suggestion (not at you personally Doug) that a CU would want or actually use 2 identical VALARMs yet consider them separate. In all my C&S time Ive yet to hear of any shipping product that allowed the user to create 2 identical alarms that were separate nor have I heard of users actually asking for it. After all, what exactly is the practical use for 2 simultaneous & identical AUDIO VALARMs that play the same sound at the same time? Does it play louder? Or is it in Stero vs Mono? Is there any actual use for having 2 PROCEDURAL alarms that run the exact same code at the exact same time? What about sending off 2 identical email notices to the exact same set of ATTENDEEs at the exact same time? I dont see how having 2 DISPLAY VALARMs triggering at the same time with the same information is really a big ticket item on any users wish list. Since we have autorepeating VALARMs (which means the VALARM could repeat, say, 1 second later for 15 times if I really really wanted it to) and we can have multiple VALARMs on any given entry, I see no real need to have multiple identical copies of VALARMs and to change iCalendar. 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 0069193C85256DD3_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/31/2003 05:16:09 PM:
> Better yet, an example of when MODIFY breaks.
>
> Take TWO VLARMS that are identical in one component.
> Withou a unique identifier  - you can not uniquly identify  the 2nd
> instance.
I claim that this is a non-sensical / practical case to use.  (Plus its the only one I could think of too.)

We dont allow multiple VDAYLIGHTs or VSTANDARDs with the exact same data to be a single VTIMEZONE and yet consider the defintions to be different.  We do not allow 2 VEVENTs in the same calendar to have the exact same set of properties and subcomponents yet call them different VEVENTs.  We even said in iCalendar that repeat instances for the same date/time are to be treated a single instance.  So why would we now invent this different consideration for VALARMs?

Taking a practical look I have to chuckle at the suggestion (not at you personally Doug) that a CU would want or actually use 2 identical VALARMs yet consider them separate.  In all my C&S time Ive yet to hear of any shipping product that allowed the user to create 2 identical alarms that were separate nor have I heard of users actually asking for it.

After all, what exactly is the practical use for 2 simultaneous & identical AUDIO VALARMs that play the same sound at the same time? Does it play louder?  Or is it in Stero vs Mono?

Is there any actual use for having 2 PROCEDURAL alarms that run the exact same code at the exact same time?  

What about sending off 2 identical email notices to the exact same set of ATTENDEEs at the exact same time?

I dont see how having 2 DISPLAY VALARMs triggering at the same time with the same information is really a big ticket item on any users wish list.  

Since we have autorepeating VALARMs (which means the VALARM could repeat, say, 1 second later for 15 times if I really really wanted it to) and we can have multiple VALARMs on any given entry, I see no real need to have multiple identical copies of VALARMs and to change iCalendar.  

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 0069193C85256DD3_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 14:31:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16198 for ; Mon, 3 Nov 2003 14:31:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JKRkT047244 for ; Mon, 3 Nov 2003 11:20:27 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3JKRTU047243 for ietf-calendar-bks; Mon, 3 Nov 2003 11:20:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JKQkT047236 for ; Mon, 3 Nov 2003 11:20:26 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA2C4AD.5070206@Royer.com> To: ietf-calendar@imc.org Subject: Re: When to publish -12 - SCOPING MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 3 Nov 2003 14:16:24 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/03/2003 02:20:11 PM, Serialize complete at 11/03/2003 02:20:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0069918285256DD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069918285256DD3_= Content-Type: text/plain; charset="US-ASCII" Doug said on 10/31/2003 03:23:09 PM: > > Go check the archives for Presons posting on 04/03/2003 02:36:12 PM > > MST under the subject "How do you get the METHOD property on a > > SEARCH". There was a brief WG flurry about it but no actual > > resolution on it > > Now go read the rest of the archives. you will find there was > a solution sent to the list. I dont see any solution in my archives. The last I saw was some discussion between you, me and Andrea about scoping and you were going to (from 04/07/2003 11:57:58 AM CST): I will update the text! from "an iCalendar" to "one or more iCalendar". And add text about grouped by METHOD (or any IANA property ... blurb...). But the text in 12-e under Section 6.1.1 CAL-QUERY looks nearly the same as in it did back then. I will go search the IMC archives and see if I missed the postings where there was a proposal and agreement on resolving this. > Do you have another proposal? I havent seen your proposal so Ill go see if I can find it before I write another. Why reinvent if I dont have to... 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 0069918285256DD3_= Content-Type: text/html; charset="US-ASCII"
Doug said on 10/31/2003 03:23:09 PM:
> > Go check the archives for Presons posting on 04/03/2003 02:36:12 PM
> > MST under the subject "How do you get the METHOD property on a
> > SEARCH".   There was a brief WG flurry about it but no actual
> > resolution on it
>
> Now go read the rest of the archives. you will find there was
> a solution sent to the list.
I dont see any solution in my archives.  The last I saw was some discussion between you, me and Andrea about scoping and you were going to (from 04/07/2003 11:57:58 AM CST):

I will update the text! from "an iCalendar" to "one or more iCalendar".
And add text about grouped by METHOD (or any IANA property ... blurb...).
But the text in 12-e under Section 6.1.1 CAL-QUERY looks nearly the same as in it did back then.  I will go search the IMC archives and see if I missed the postings where there was a proposal and agreement on resolving this.

> Do you have another proposal?
I havent seen your proposal so Ill go see if I can find it before I write another.  Why reinvent if I dont have to...

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 0069918285256DD3_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 14:56:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17556 for ; Mon, 3 Nov 2003 14:56:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JkhkT048170 for ; Mon, 3 Nov 2003 11:46:43 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3JkhbF048169 for ietf-calendar-bks; Mon, 3 Nov 2003 11:46:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JkgkT048156 for ; Mon, 3 Nov 2003 11:46:42 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <1067102230.2588.49.camel@snowflake> To: Damon Chaplin Cc: ietf-calendar@imc.org, Tim Hare Subject: Re: vzic Olson->iCalendar timezone converter update MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 3 Nov 2003 14:46:34 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/03/2003 02:46:45 PM, Serialize complete at 11/03/2003 02:46:45 PM Content-Type: multipart/alternative; boundary="=_alternative 006C54AE85256DD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C54AE85256DD3_= Content-Type: text/plain; charset="US-ASCII" Damon wrote on 10/25/2003 01:17:10 PM: > Yes, you can drop the BEGIN/END VCALENDARs, and just leave 1 pair. Dont forget to trim out the other duplicate VCALENDAR level properties like PRODID, VERSION, etc too... 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 006C54AE85256DD3_= Content-Type: text/html; charset="US-ASCII"
Damon wrote on 10/25/2003 01:17:10 PM:
> Yes, you can drop the BEGIN/END VCALENDARs, and just leave 1 pair.
Dont forget to trim out the other duplicate VCALENDAR level properties like PRODID, VERSION, etc too...

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 006C54AE85256DD3_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 14:59:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17712 for ; Mon, 3 Nov 2003 14:59:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JkgkT048164 for ; Mon, 3 Nov 2003 11:46:42 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3JkgM6048163 for ietf-calendar-bks; Mon, 3 Nov 2003 11:46:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3JkgkT048155 for ; Mon, 3 Nov 2003 11:46:42 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3F96D215.E2E13711@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: CAP-12-e: Alarms and SEQUENCE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 3 Nov 2003 14:33:59 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/03/2003 02:46:44 PM, Serialize complete at 11/03/2003 02:46:44 PM Content-Type: multipart/alternative; boundary="=_alternative 006B2DBA85256DD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B2DBA85256DD3_= Content-Type: text/plain; charset="US-ASCII" Mark wrote on 10/22/2003 02:53:09 PM: > You still propse to break MODIFY wihout any solution. No one > wants to break modify. Not true. Go see last weeks followup to Doug regarding this. > I do not know which version if any draft or published text you > have been reading, but I can not find ANY other unique identifier > for VALARMS. What is it? You must have missed the threads from ~Oct/Nov 2001 that was again touched on in Jan/Feb 2002. Go check out http://www.imc.org/ietf-calendar/mail-archive/msg02442.html for the WG decision regarding the creation of ALARMID (not SEQUENCE). In fact, as part of the revisit in 2002 under the subject "VALARM: UID VS ALARMID" Doug wrote: I prefer ALARMID. and so did ~all the others that I can see. Yet somehow, without any WG discussion I can find, the ALARMID property was replaced by SEQUENCE. 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 006B2DBA85256DD3_= Content-Type: text/html; charset="US-ASCII"
Mark wrote on 10/22/2003 02:53:09 PM:
> You still propse to break MODIFY wihout any solution. No one
> wants to break modify.
Not true.  Go see last weeks followup to Doug regarding this.

> I do not know which version if any draft or published text you
> have been reading, but I can not find ANY other unique identifier
> for VALARMS. What is it?
You must have missed the threads from ~Oct/Nov 2001 that was again touched on in Jan/Feb 2002.  Go check out http://www.imc.org/ietf-calendar/mail-archive/msg02442.html for the WG decision regarding the creation of ALARMID (not SEQUENCE).  In fact, as part of the revisit in 2002 under the subject "VALARM: UID VS ALARMID" Doug wrote:

I prefer ALARMID.

and so did ~all the others that I can see.  Yet somehow, without any WG discussion I can find, the ALARMID property was replaced by SEQUENCE.

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 006B2DBA85256DD3_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 15:49:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20628 for ; Mon, 3 Nov 2003 15:49:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3KY2kT050407 for ; Mon, 3 Nov 2003 12:34:02 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3KY2lt050406 for ietf-calendar-bks; Mon, 3 Nov 2003 12:34:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3KXukT050392 for ; Mon, 3 Nov 2003 12:33:57 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: TimHare@comcast.net Cc: ietf-calendar@imc.org Subject: Re: different calendar scales MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 3 Nov 2003 15:33:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/03/2003 03:33:57 PM, Serialize complete at 11/03/2003 03:33:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0070A70385256DD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070A70385256DD3_= Content-Type: text/plain; charset="US-ASCII" Tim suggested on 09/23/2003 02:24:11 AM: > I propose that CAP 10.7 be revised so that calscale-props is included as a > required response to the GET-CAPABILITY command, and that any > examples for GET- > CAPABILITY be modified to show CALSCALE: GREGORIAN, HEBREW, JALALIL > CRLF (or a > similar list of calendar scales) being returned. Hmm, Mark didn't hop up and down on you for trying to make a change but then again noone seems to have responded (or Im missing WG traffic). The suggestion has merit in that it would make adding support for non-GREGORIAN scales easy however adding to CAP is against the editors mantra. I like the idea but since there are currently no other calendar scales out there nor are there any proposals for any Im not sure there is sufficent need at this time. Of course putting it in after the fact can be harder (imagine a CAP 1.0 client trying to use CAP to a HEBREW only CS... Sucks to be that CU!) There are 2 ways to approach this and neither cause any big delays in CAP. 1: Simply add some text to Section 10.7 GET-CAPABILITY Command that says something like: For this version of CAP, both sides are assumed to support only the GREGORIAN calendar scale entries. Entries in other calendar scales MUST NOT be sent to this version of a CAP implementation. 2: We can update CAP to actually return CALSCALE in the ABNF: cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF ; The following properties may be in any order. ; prodid version reply-cmd other-props "BEGIN" ":" "VREPLY" CRLF ; The following properties may be in any order. ; cap-version calscale car-level components stores-expanded maxdate mindate itip-version max-comp-size multipart query-level recur-accepted recur-expand recur-limit other-props "END" ":" "VREPLY" CRLF "END" ":" "VCALENDAR" CRLF and then add some text to the command that says something like: The "GET-CAPABILITY" reply MUST include a CALSCALE property. This indicates all the calendar scales which the sender understands. Data that is not in one of those calendar scales MUST NOT be sent. This would make the issue of a CAP 1.0 CUA talking to a HEBREW-only CS more easily detected and thus fail nicer ("The CS you are connecting only supports calendars in a scale I do not understand so I am unable to work with it. Please upgrade me or use a different server.") Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 0070A70385256DD3_= Content-Type: text/html; charset="US-ASCII"
Tim suggested on 09/23/2003 02:24:11 AM:
> I propose that CAP 10.7 be revised so that calscale-props is included as a
> required response to the GET-CAPABILITY command, and that any
> examples for GET-
> CAPABILITY be modified to show CALSCALE: GREGORIAN, HEBREW, JALALIL
> CRLF (or a
> similar list of calendar scales) being returned.

Hmm, Mark didn't hop up and down on you for trying to make a change but then again noone seems to have responded (or Im missing WG traffic).   The suggestion has merit in that it would make adding support for non-GREGORIAN scales easy however adding to CAP is against the editors mantra.  

I like the idea but since there are currently no other calendar scales out there nor are there any proposals for any Im not sure there is sufficent need at this time.  Of course putting it in after the fact can be harder (imagine a CAP 1.0 client trying to use CAP to a HEBREW only CS...  Sucks to be that CU!)

There are 2 ways to approach this and neither cause any big delays in CAP.  

1: Simply add some text to Section 10.7 GET-CAPABILITY Command that says something like:

    For this version of CAP, both sides are assumed to support only the GREGORIAN calendar scale entries.  Entries in other calendar scales MUST NOT be sent to this version of a CAP implementation.

2: We can update CAP to actually return CALSCALE in the ABNF:

   cap-vreply     = "BEGIN" ":" "VCALENDAR" CRLF
                  ; The following properties may be in any order.
                  ;
                   prodid
                   version
                   reply-cmd
                   other-props
                   "BEGIN" ":" "VREPLY" CRLF
                   ; The following properties may be in any order.
                   ;
                   cap-version
                    calscale
                   car-level
                   components
                   stores-expanded
                   maxdate
                   mindate
                   itip-version
                   max-comp-size
                   multipart
                   query-level
                   recur-accepted
                   recur-expand
                   recur-limit
                   other-props
                   "END" ":" "VREPLY" CRLF
                  "END" ":" "VCALENDAR" CRLF

and then add some text to the command that says something like:

    The "GET-CAPABILITY" reply MUST include a CALSCALE property.  This indicates all the calendar scales which the sender understands.  Data that is not in one of those calendar scales MUST NOT be sent.

This would make the issue of a CAP 1.0 CUA talking to a HEBREW-only CS more easily detected and thus fail nicer ("The CS you are connecting only supports calendars in a scale I do not understand so I am unable to work with it.  Please upgrade me or use a different server.")

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 0070A70385256DD3_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 15:50:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20649 for ; Mon, 3 Nov 2003 15:50:01 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3KXwkT050404 for ; Mon, 3 Nov 2003 12:33:58 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3KXwOn050403 for ietf-calendar-bks; Mon, 3 Nov 2003 12:33:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3KXukT050391 for ; Mon, 3 Nov 2003 12:33:57 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-e: CAP-VERSION Property MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 3 Nov 2003 15:19:36 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/03/2003 03:33:57 PM, Serialize complete at 11/03/2003 03:33:57 PM Content-Type: multipart/alternative; boundary="=_alternative 006F5ADA85256DD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F5ADA85256DD3_= Content-Type: text/plain; charset="US-ASCII" In looking at Tims proposal I noticed that CAP-VERSION is not properly described/defined. 12-e says: Description: This specifies the version of CAP that the endpoint supports. The list is a comma separated list of RFC numbers supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT). Formal Definition: The property is defined by the following notation: cap-version = "CAP-VERSION" other-params ":" text CRLF Example: The following are examples of this property: CAP-VERSION:XXXX 1: Is there a reason CAP-VERSION is not defined like VERSION is in iCalendar? That is, why it is not a numeric value or formatted like a numeric value? It used to be last I checked on it back in CAP-09: CAP-VERSION 1 Version of CAP. It 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". 2: When did we say CAP-VERSION was to be the RFC number? Is there any real use for that over using the numeric scheme like we did in iCalendar? If we do opt to stay with "text" then the last line there needs to have the same "(NOTE 'XXXX' WILL BE REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT)." added to it to ensure the change is uniform. 3: In later examples we use numeric values ala VERSION. For example, page 112 has: L: CAP-VERSION:1.0 If we are avoiding using numeric values and go with RFC numbers then this example needs to be changed and flagged too for update on RFC number assignment. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 006F5ADA85256DD3_= Content-Type: text/html; charset="US-ASCII"
In looking at Tims proposal I noticed that CAP-VERSION is not properly described/defined.  12-e says:

   Description: This specifies the version of CAP that the endpoint
  supports. The list is a comma separated list of RFC numbers
  supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE
  REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT).
   Formal Definition: The property is defined by the following notation:

  cap-version   = "CAP-VERSION" other-params ":" text CRLF

  Example: The following are examples of this property:

  CAP-VERSION:XXXX
1: Is there a reason CAP-VERSION is not defined like VERSION is in iCalendar?  That is, why it is not a numeric value or formatted like a numeric value?  It used to be last I checked on it back in CAP-09:

     CAP-VERSION        1     Version of CAP. It 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".
2: When did we say CAP-VERSION was to be the RFC number?  Is there any real use for that over using the numeric scheme like we did in iCalendar?  If we do opt to stay with "text" then the last line there needs to have the same "(NOTE 'XXXX' WILL BE REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT)." added to it to ensure the change is uniform.

3: In later examples we use numeric values ala VERSION.  For example, page 112 has:

      L: CAP-VERSION:1.0
If we are avoiding using numeric values and go with RFC numbers then this example needs to be changed and flagged too for update on RFC number assignment.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 006F5ADA85256DD3_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 16:33:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22898 for ; Mon, 3 Nov 2003 16:33:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3LKkkT051840 for ; Mon, 3 Nov 2003 13:20:46 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3LKkBK051839 for ietf-calendar-bks; Mon, 3 Nov 2003 13:20:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA3LKikT051833 for ; Mon, 3 Nov 2003 13:20:45 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003110316350701368 for ; Mon, 03 Nov 2003 16:35:07 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Nov 2003 16:17:52 -0500 Message-ID: <3FA6C600.6030105@centive.com> Date: Mon, 03 Nov 2003 16:17:52 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar scales References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2003 21:17:52.0113 (UTC) FILETIME=[F0B6BE10:01C3A24F] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > I like the idea but since there are currently no other calendar scales > out there nor are there any proposals for any Im not sure there is > sufficent need at this time. Of course putting it in after the fact > can be harder (imagine a CAP 1.0 client trying to use CAP to a HEBREW > only CS... Sucks to be that CU!) Yeah, but that'd be the case either way; putting scales into the capabilities just means you *know* it sucks to be you. I think, if we ever get non-Gregorian scales, we'll have to mandate that all iCalendar implementations support Gregorian, for interop with existing implementations. As I understand it, the only place where this would be sticky is in RRULE. Individual dates can always be translated; but people who use a lunar calendar, say, may want to schedule recurring events according to patterns that have no equivalent in a solar calendar. If so, then the RRULEs from a lunar scale simply could not be translated into Gregorian. But there really isn't any good solution for that; people who want to schedule events based on phase of the moon will not be able to do so when communicating with people whose CUs don't support it. "Oh, hell, let's leave the problem for future generations." "Good idea. It'll make them feel more involved." -- Doonesbury (two of the authors of the US Constitution, discussing slavery) -- /===============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===============================================================| |"There will be no more there. We will all be here."--networkMCI| |ad | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 3 16:54:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24509 for ; Mon, 3 Nov 2003 16:54:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3LgYkT052527 for ; Mon, 3 Nov 2003 13:42:34 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3LgYWe052526 for ietf-calendar-bks; Mon, 3 Nov 2003 13:42:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3LgWkT052519 for ; Mon, 3 Nov 2003 13:42:32 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA3LgVc0002164 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Nov 2003 13:42:32 -0800 Message-ID: <3FA6CBC2.8060402@Royer.com> Date: Mon, 03 Nov 2003 14:42:26 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: CAP-VERSION Property References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070202090502060808000606" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070202090502060808000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In looking at Tims proposal I noticed that CAP-VERSION is not properly > described/defined. 12-e says: > > Description: This specifies the version of CAP that the endpoint > supports. The list is a comma separated list of RFC numbers > supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE > REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT). > > Formal Definition: The property is defined by the following notation: > > cap-version = "CAP-VERSION" other-params ":" text CRLF > > Example: The following are examples of this property: > > CAP-VERSION:XXXX > > 1: Is there a reason CAP-VERSION is not defined like VERSION is in > iCalendar? It is a multivalued field unlike VERSION. So you could say you are RFC X, and Z compatible skipping Y if needed. > That is, why it is not a numeric value or formatted like a numeric > value? It used to be last I checked on it back in CAP-09: > > CAP-VERSION 1 Version of CAP. It 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". > > 2: When did we say CAP-VERSION was to be the RFC number? As you pointed out about it must have been -10 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070202090502060808000606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTAzMjE0MjI2WjAjBgkqhkiG9w0BCQQxFgQUoiUcKUmvgbLP/HTnouQ8 E9mC9vgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAcu5FgVhBMyxFdGq2w8KaHL7JfhbidWuftLm4o7EgKQWdHgefX6PefoGvSt506JEo TCPpnI9Yez/y+o37ci74Nl9hp5+dR7RHDnImlnDwPuDblDn0T511wPehnrUmCjvwF5d/4Qar r17ZK62p5M+xEQ7lq2iL67adrCJwgJV30b8mWVTBkWz2UwZRZe2eI/7gAurnB4jKV+0SZyWv pZV2mvu1SxpEj6A40InG4ymNYRdZTyhQ+tAVedRAKsAcIKfV113FdIWQWp7MrTpzBrZsUF1W 3pE5cW12KhlMOWwZE35zc3hLM64VNF6Whg1TJWkcIzpxCBWEXVuLe5rW6LPZ8gAAAAAAAA== --------------ms070202090502060808000606-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 16:58:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25583 for ; Mon, 3 Nov 2003 16:58:09 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3LcUkT052383 for ; Mon, 3 Nov 2003 13:38:30 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA3LcUWn052381 for ietf-calendar-bks; Mon, 3 Nov 2003 13:38:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3LcSkT052376 for ; Mon, 3 Nov 2003 13:38:28 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA3LcNc0002087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Nov 2003 13:38:25 -0800 Message-ID: <3FA6CAC9.20607@Royer.com> Date: Mon, 03 Nov 2003 14:38:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090703020807040607090707" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090703020807040607090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 10/31/2003 05:16:09 PM: > > Better yet, an example of when MODIFY breaks. > > > > Take TWO VLARMS that are identical in one component. > > Withou a unique identifier - you can not uniquly identify the 2nd > > instance. > > I claim that this is a non-sensical / practical case to use. (Plus > its the only one I could think of too.) So in other words - you can't make it work. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090703020807040607090707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTAzMjEzODE3WjAjBgkqhkiG9w0BCQQxFgQUiJMWlJBoahC4k1xh+lip FreO15IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAe1dStRq8nBlOA/YhNrdjClDofWd7KZIM/abSHD0IZdM5SyColeF6b2iIJTMcyriZ 9kLtxmV2yzHD6Mo/TDFcSKN7znQgM+iw65NFRpk2mFUw5TUGzLyCNxPjqtjlmdo9k93AbB8v SCIOjbHz3tx9R6pOoNr02tJVNaiVH+NHYG5DDFfFlj0SMLwqnM/v9T6G7XdzNYDA3Aaye7vh QCMEEO2yBnJoKtTXZyFu2vYGXf0sRjqigKuZ2TFw/TjuBHZQ1gHLqFAnx58kMrMyB3okdvx6 1weiP1gDkp8tXBxyTRNzJnc5aekVXu26kFr1zhFC1p6DkLIf2YR0jONxuWXXwQAAAAAAAA== --------------ms090703020807040607090707-- From owner-ietf-calendar@mail.imc.org Mon Nov 3 21:16:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09162 for ; Mon, 3 Nov 2003 21:16:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA423XkT061404 for ; Mon, 3 Nov 2003 18:03:33 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA423XkE061403 for ietf-calendar-bks; Mon, 3 Nov 2003 18:03:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA423TkT061395 for ; Mon, 3 Nov 2003 18:03:31 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (rwcrmhc13) with SMTP id <2003110402032601500r0tcle> (Authid: TimHare); Tue, 4 Nov 2003 02:03:26 +0000 Message-Id: <5.2.1.1.0.20031103205512.00a30b20@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 03 Nov 2003 20:57:23 -0500 To: Bruce_Kahn@notesdev.ibm.com From: Tim Hare Subject: Re: different calendar scales Cc: ietf-calendar@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I had in mind more the Hebrew CUA asking the CS if it could use the Hebrew calendar when storing items; but your examples work as well. I am still in favor of this small addition to the GET-CAPABILITY return, since anything that makes things fail more gracefully in my book is a good thing. Tim Hare Interested Bystander, Non-Inc. At 03:33 PM 11/3/03 -0500, Bruce_Kahn@notesdev.ibm.com wrote: >Tim suggested on 09/23/2003 02:24:11 AM: > > I propose that CAP 10.7 be revised so that calscale-props is included as a > > required response to the GET-CAPABILITY command, and that any > > examples for GET- > > CAPABILITY be modified to show CALSCALE: GREGORIAN, HEBREW, JALALIL > > CRLF (or a > > similar list of calendar scales) being returned. > >Hmm, Mark didn't hop up and down on you for trying to make a change but >then again noone seems to have responded (or Im missing WG traffic). The >suggestion has merit in that it would make adding support for >non-GREGORIAN scales easy however adding to CAP is against the editors >mantra. > >I like the idea but since there are currently no other calendar scales out >there nor are there any proposals for any Im not sure there is sufficent >need at this time. Of course putting it in after the fact can be harder >(imagine a CAP 1.0 client trying to use CAP to a HEBREW only CS... Sucks >to be that CU!) > >There are 2 ways to approach this and neither cause any big delays in CAP. > >1: Simply add some text to Section 10.7 GET-CAPABILITY Command that says >something like: > > For this version of CAP, both sides are assumed to support only the > GREGORIAN calendar scale entries. Entries in other calendar scales MUST > NOT be sent to this version of a CAP implementation. > >2: We can update CAP to actually return CALSCALE in the ABNF: > > cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF > ; The following properties may be in any order. > ; > prodid > version > reply-cmd > other-props > "BEGIN" ":" "VREPLY" CRLF > ; The following properties may be in any order. > ; > cap-version > calscale > car-level > components > stores-expanded > maxdate > mindate > itip-version > max-comp-size > multipart > query-level > recur-accepted > recur-expand > recur-limit > other-props > "END" ":" "VREPLY" CRLF > "END" ":" "VCALENDAR" CRLF > >and then add some text to the command that says something like: > > The "GET-CAPABILITY" reply MUST include a CALSCALE property. This > indicates all the calendar scales which the sender understands. Data > that is not in one of those calendar scales MUST NOT be sent. > >This would make the issue of a CAP 1.0 CUA talking to a HEBREW-only CS >more easily detected and thus fail nicer ("The CS you are connecting only >supports calendars in a scale I do not understand so I am unable to work >with it. Please upgrade me or use a different server.") > >Bruce >=========================================================================== >Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com >Messaging & Collaboration Phone: 978.399.6496 >IBM Software Group FAX: and nothing but the FAX... >Warning: Dates in Calendar are closer than they appear. From owner-ietf-calendar@mail.imc.org Tue Nov 4 10:35:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18770 for ; Tue, 4 Nov 2003 10:35:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FLNkT059195 for ; Tue, 4 Nov 2003 07:21:23 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4FLMAC059194 for ietf-calendar-bks; Tue, 4 Nov 2003 07:21:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FLMkT059184 for ; Tue, 4 Nov 2003 07:21:22 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA6CBC2.8060402@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-e: CAP-VERSION Property MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 4 Nov 2003 10:18:35 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/04/2003 10:21:19 AM, Serialize complete at 11/04/2003 10:21:19 AM Content-Type: multipart/alternative; boundary="=_alternative 0053C6E985256DD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053C6E985256DD4_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/03/2003 04:42:26 PM: > > 1: Is there a reason CAP-VERSION is not defined like VERSION is in > > iCalendar? > > It is a multivalued field unlike VERSION. So you could say you are RFC > X, and Z compatible > skipping Y if needed. My appologies for not be more precise in the question. I was referring to using a numeric values like VERSION (which actually is biparted): version = "VERSION" verparam ":" vervalue CRLF verparam = *(";" xparam) vervalue = "2.0" ;This memo / maxver / (minver ";" maxver) minver = ;Minimum iCalendar version needed to parse the iCalendar object maxver = ;Maximum iCalendar version needed to parse the iCalendar object So to rephrase a bit: Is there a reason that CAP-VERSION is not defined using something like: cap-version = "CAP-VERSION" capverparams ":" capvervalue *("," capvervalue) CRLF capverparams = *( ; the following are optional, ; and MAY occur more than once (";" iana-params) / (";" xparam) ) capvervalue = "1.0" ;This memo / iana-capver iana-capver = ;Any other IANA registered CAP version that the sender supports This is how we defined recurrence and exception dates (multivalued) and VERSION ("1.0" instead of the RFC number) in iCalendar. > > 2: When did we say CAP-VERSION was to be the RFC number? > > As you pointed out about it must have been -10 Did we actually discuss exchanging "1.0" for the RFC number at some point? I dont recall any WG discussion on it nor can I find any in the archives. A check of the archives for "CAP-VERSION" shows we talked about the GET-CAPABILITY command being mandated for all implementations back ~Oct/Nov 2002 and back then we used CAP-VERSION:1.0. On 15-Apr-2003 in the thread "Diffs - ftp://royer.com/pub/CALSCH/cap.txt" we were using "1.0" still. The next time I find a reference is Dougs "CAP ABNF" posting dated 06/14/2003 05:38:19 PM CST that had: 254 cap-version = "CAP-VERSION" other-params ":" text CRLF but nothing inbetween nor anything that discussed the change on the list. Hence my question: _When_ did we say CAP-VERSION was to be the RFC number? 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 0053C6E985256DD4_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/03/2003 04:42:26 PM:
> > 1: Is there a reason CAP-VERSION is not defined like VERSION is in
> > iCalendar?
>
> It is a multivalued field unlike VERSION. So you could say you are RFC
> X, and Z compatible
> skipping Y if needed.
My appologies for not be more precise in the question.  I was referring to using a numeric values like VERSION (which actually is biparted):

     version    = "VERSION" verparam ":" vervalue CRLF

    verparam   = *(";" xparam)

    vervalue   = "2.0"         ;This memo
               / maxver
               / (minver ";" maxver)
     minver     = <A IANA registered iCalendar version identifier>
    ;Minimum iCalendar version needed to parse the iCalendar object

    maxver     = <A IANA registered iCalendar version identifier>
    ;Maximum iCalendar version needed to parse the iCalendar object
So to rephrase a bit: Is there a reason that CAP-VERSION is not defined using something like:

   cap-version   = "CAP-VERSION" capverparams ":" capvervalue *("," capvervalue) CRLF
  capverparams   = *(
               ; the following are optional,
               ; and MAY occur more than once

               (";" iana-params) /
               (";" xparam)
                )

  capvervalue   = "1.0"         ;This memo
               / iana-capver
   iana-capver   = <A IANA registered CAP version identifier>
    ;Any other IANA registered CAP version that the sender supports
This is how we defined recurrence and exception dates (multivalued) and VERSION ("1.0" instead of the RFC number) in iCalendar.

> > 2: When did we say CAP-VERSION was to be the RFC number?
>
> As you pointed out about it must have been -10
Did we actually discuss exchanging "1.0" for the RFC number at some point?  I dont recall any WG discussion on it nor can I find any in the archives.  

A check of the archives for "CAP-VERSION" shows we talked about the GET-CAPABILITY command being mandated for all implementations back ~Oct/Nov 2002 and back then we used CAP-VERSION:1.0.  

On 15-Apr-2003 in the thread "Diffs - ftp://royer.com/pub/CALSCH/cap.txt" we were using "1.0" still.

The next time I find a reference is Dougs "CAP ABNF" posting dated 06/14/2003 05:38:19 PM CST that had:

   254   cap-version   = "CAP-VERSION" other-params ":" text CRLF
but nothing inbetween nor anything that discussed the change on the list.  Hence my question: _When_ did we say CAP-VERSION was to be the RFC number?  

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 0053C6E985256DD4_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 10:50:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19576 for ; Tue, 4 Nov 2003 10:50:12 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FZqkT059992 for ; Tue, 4 Nov 2003 07:35:52 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4FZqx8059991 for ietf-calendar-bks; Tue, 4 Nov 2003 07:35:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FZpkT059984 for ; Tue, 4 Nov 2003 07:35:51 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA6CAC9.20607@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Alarms and SEQUENCE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 4 Nov 2003 10:32:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/04/2003 10:35:47 AM, Serialize complete at 11/04/2003 10:35:47 AM Content-Type: multipart/alternative; boundary="=_alternative 0055180285256DD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055180285256DD4_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/03/2003 04:38:17 PM: > > I claim that this is a non-sensical / practical case to use. (Plus > > its the only one I could think of too.) > > So in other words - you can't make it work. I claim your example is not one thats worth considering because its non-realistic. As I pointed out before its not a feature that exists now (unless you've got some product now that has it) because its just not something people do in practice. Please explain the real need or benefit of having two identical VALARMs on the same entity that do the exact same thing and repeat the exact same number of times?? They are indistinguishable from each other to users ("Gee was that WAV the 1st AUDIO alarm I set or the 2nd??") so there is no benefit in them. Why would a CU want to have 2 AUDIO alarms that play the exact same WAV at the exact same time and autorepeats the same number of times? Does users really want to have multiple dialogs popup at the exact same time with the exact same contents and autorepeat the same number of times? Who here realistically wants to have an email notice sent multiple times at the exact same to the exact same invitees and autorepeat the same number of times? Ive never ever once heard a user say "Gee, I wish I could set 10 alarms that all do the exact same thing at the exact same time on this particular meeting. Why cant I?" Just as in iCalendar we said that all repeat instances that have the same date/time values are a single instance I claim the same is true for VALARMs. If your alarm clock at home has 2 alarms on it, do you set both of your alarms for the same time in order to avoid sleepting thru that big meeting? Or do you stagger them in case you hit Off instead of Snooze? I for one stagger them, just in case. 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 0055180285256DD4_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/03/2003 04:38:17 PM:
> > I claim that this is a non-sensical / practical case to use.  (Plus
> > its the only one I could think of too.)
>
> So in other words - you can't make it work.
I claim your example is not one thats worth considering because its non-realistic.  As I pointed out before its not a feature that exists now (unless you've got some product now that has it) because its just not something people do in practice.

Please explain the real need or benefit of having two identical VALARMs on the same entity that do the exact same thing and repeat the exact same number of times??  They are indistinguishable from each other to users ("Gee was that WAV the 1st AUDIO alarm I set or the 2nd??") so there is no benefit in them.

Why would a CU want to have 2 AUDIO alarms that play the exact same WAV at the exact same time and autorepeats the same number of times?

Does users really want to have multiple dialogs popup at the exact same time with the exact same contents and autorepeat the same number of times?

Who here realistically wants to have an email notice sent multiple times at the exact same to the exact same invitees and autorepeat the same number of times?

Ive never ever once heard a user say "Gee, I wish I could set 10 alarms that all do the exact same thing at the exact same time on this particular meeting.  Why cant I?"  Just as in iCalendar we said that all repeat instances that have the same date/time values are a single instance I claim the same is true for VALARMs.

If your alarm clock at home has 2 alarms on it, do you set both of your alarms for the same time in order to avoid sleepting thru that big meeting?  Or do you stagger them in case you hit Off instead of Snooze?  I for one stagger them, just in case.

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 0055180285256DD4_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 11:21:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21173 for ; Tue, 4 Nov 2003 11:21:57 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4G7WkT061045 for ; Tue, 4 Nov 2003 08:07:32 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4G7WWx061044 for ietf-calendar-bks; Tue, 4 Nov 2003 08:07:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4G7VkT061039 for ; Tue, 4 Nov 2003 08:07:32 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA6C600.6030105@centive.com> To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: different calendar scales MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 4 Nov 2003 10:56:20 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/04/2003 11:07:26 AM, Serialize complete at 11/04/2003 11:07:26 AM Content-Type: multipart/alternative; boundary="=_alternative 00573BD285256DD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00573BD285256DD4_= Content-Type: text/plain; charset="US-ASCII" John replied on 11/03/2003 04:17:52 PM: > I think, if we ever get non-Gregorian scales, we'll have to mandate that > all iCalendar implementations support Gregorian, for interop with > existing implementations. That defeats the purpose of having CALSCALE in the entity doesnt it? The reason that CALSCALE exists was so that going forward ANY CUA who does the right thing and checks for CALSCALE first will be able to fail in a graceful way instead of accidentally running amok off in the weeds. Well behaved iCalendar implementations SHOULD be checking CALSCALE first and if its there, making sure it is one they grok before trying to deal with any time/date values on ANY property, not just recurrences. Its better to put up a dialog with "This iCalendar is based on the 'MiddleEarth' calendar scale which I do not understand. I am unable to properly open and display it. Do you want me to notify the sender of this or just toss it in the trash?" than try to unwind recurrence rules that will appear malformed or invalid and put cruft on the users calendar (or crash in doing parsing attempts or...). More practically, if you ignore the CALSCALE:HEBREW and treat the RDATEs as GREGORIAN date/time values you could be in a world of hirt. For example, 15-Dec-1998 (GREGORIAN; 19981215) is 26-Kislev-5759 (Hebrew; Maybe 57590326 in ISO-9601 notation). If an older iCalendar client ignored CALSCALE they could misparse it and put an entry on the users calendar for ~3700 years in the future instead of ~5 years ago. Also, you need to factor in that not all data is going to be CAP sourced. It may arrive via iMIP or some other means. > But there really isn't any good solution for > that; people who want to schedule events based on phase of the moon will > not be able to do so when communicating with people whose CUs don't > support it. Thats why we never said all C&S MUST be in GREGORIAN calendar scale and why we invented the CALSCALE property. So do you think adding calscale to the GET-CAPABILITY response is a good or bad thing?? I even provided sample text and ABNF for Doug to use if the group thinks its a smart thing 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 00573BD285256DD4_= Content-Type: text/html; charset="US-ASCII"
John replied on 11/03/2003 04:17:52 PM:
> I think, if we ever get non-Gregorian scales, we'll have to mandate that
> all iCalendar implementations support Gregorian, for interop with
> existing implementations.  

That defeats the purpose of having CALSCALE in the entity doesnt it?  The reason that CALSCALE exists was so that going forward ANY CUA who does the right thing and checks for CALSCALE first will be able to fail in a graceful way instead of accidentally running amok off in the weeds.  Well behaved iCalendar implementations SHOULD be checking CALSCALE first and if its there, making sure it is one they grok before trying to deal with any time/date values on ANY property, not just recurrences.  

Its better to put up a dialog with "This iCalendar is based on the 'MiddleEarth' calendar scale which I do not understand.  I am unable to properly open and display it.  Do you want me to notify the sender of this or just toss it in the trash?" than try to unwind recurrence rules that will appear malformed or invalid and put cruft on the users calendar (or crash in doing parsing attempts or...).

More practically, if you ignore the CALSCALE:HEBREW and treat the RDATEs as GREGORIAN date/time values you could be in a world of hirt.  For example, 15-Dec-1998 (GREGORIAN; 19981215) is 26-Kislev-5759 (Hebrew; Maybe 57590326 in ISO-9601 notation).  If an older iCalendar client ignored CALSCALE they could misparse it and put an entry on the users calendar for ~3700 years in the future instead of ~5 years ago.

Also, you need to factor in that not all data is going to be CAP sourced.  It may arrive via iMIP or some other means.

>                          But there really isn't any good solution for
> that; people who want to schedule events based on phase of the moon will
> not be able to do so when communicating with people whose CUs don't
> support it.

Thats why we never said all C&S MUST be in GREGORIAN calendar scale and why we invented the CALSCALE property.

So do you think adding calscale to the GET-CAPABILITY response is a good or bad thing??  I even provided sample text and ABNF for Doug to use if the group thinks its a smart thing 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 00573BD285256DD4_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 11:57:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22559 for ; Tue, 4 Nov 2003 11:57:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4GhNkT062394 for ; Tue, 4 Nov 2003 08:43:23 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4GhNiD062393 for ietf-calendar-bks; Tue, 4 Nov 2003 08:43:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA4GhLkT062386 for ; Tue, 4 Nov 2003 08:43:22 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003110411573601233 for ; Tue, 04 Nov 2003 11:57:36 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Nov 2003 11:40:20 -0500 Message-ID: <3FA7D674.30906@centive.com> Date: Tue, 04 Nov 2003 11:40:20 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar scales References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2003 16:40:20.0462 (UTC) FILETIME=[55F830E0:01C3A2F2] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Its better to put up a dialog with "This iCalendar is based on the > 'MiddleEarth' calendar scale which I do not understand. Yeah, OK; it's analogous to character set tagging. > So do you think adding calscale to the GET-CAPABILITY response is a > good or bad thing?? Um...probably a good thing, on reflection. -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |I'm a zygote, he's a zygote, she's a zygote, wouldn't you like to| |be a zygote, too? | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 4 14:01:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28075 for ; Tue, 4 Nov 2003 14:01:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4Im6kT067341 for ; Tue, 4 Nov 2003 10:48:06 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4Im6cZ067340 for ietf-calendar-bks; Tue, 4 Nov 2003 10:48:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4Im5kT067318 for ; Tue, 4 Nov 2003 10:48:05 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA4Ilr84016244 for ; Tue, 4 Nov 2003 11:47:53 -0700 (MST) Message-ID: <3FA7F459.48FFEEF3@INET-Calendar.net> Date: Tue, 04 Nov 2003 11:47:53 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-e: CAP-VERSION Property References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > > 2: When did we say CAP-VERSION was to be the RFC number? > > > > As you pointed out about it must have been -10 > > Did we actually discuss exchanging "1.0" for the RFC number at some > point? Look closer. As usual - you miss what you disagree with. From owner-ietf-calendar@mail.imc.org Tue Nov 4 14:04:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28264 for ; Tue, 4 Nov 2003 14:04:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4IqNkT067454 for ; Tue, 4 Nov 2003 10:52:23 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4IqN04067453 for ietf-calendar-bks; Tue, 4 Nov 2003 10:52:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4IqMkT067447 for ; Tue, 4 Nov 2003 10:52:22 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA4IqI84016385 for ; Tue, 4 Nov 2003 11:52:18 -0700 (MST) Message-ID: <3FA7F562.F08156A8@INET-Calendar.net> Date: Tue, 04 Nov 2003 11:52:18 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar scales References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > John replied on 11/03/2003 04:17:52 PM: > > I think, if we ever get non-Gregorian scales, we'll have to mandate > that > > all iCalendar implementations support Gregorian, for interop with > > existing implementations. > > That defeats the purpose of having CALSCALE in the entity doesnt it? The original proposal was the CAPABILITY reply be extended. Please read all of the posts before replying with more underinformed comments. From owner-ietf-calendar@mail.imc.org Tue Nov 4 14:15:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28803 for ; Tue, 4 Nov 2003 14:15:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4J5HkT067828 for ; Tue, 4 Nov 2003 11:05:17 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4J5HEg067827 for ietf-calendar-bks; Tue, 4 Nov 2003 11:05:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA4J5FkT067816 for ; Tue, 4 Nov 2003 11:05:16 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003110414193808979 for ; Tue, 04 Nov 2003 14:19:38 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Nov 2003 14:02:22 -0500 Message-ID: <3FA7F7BE.8050303@centive.com> Date: Tue, 04 Nov 2003 14:02:22 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar scales References: <3FA7F562.F08156A8@INET-Calendar.net> In-Reply-To: <3FA7F562.F08156A8@INET-Calendar.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2003 19:02:22.0391 (UTC) FILETIME=[2D6F5C70:01C3A306] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Smith wrote: >Bruce_Kahn@notesdev.ibm.com wrote: > > >>John replied on 11/03/2003 04:17:52 PM: >> >> >>>I think, if we ever get non-Gregorian scales, we'll have to mandate >>> >>> >>that >> >> >>>all iCalendar implementations support Gregorian, for interop with >>>existing implementations. >>> >>> >>That defeats the purpose of having CALSCALE in the entity doesnt it? >> >> > >The original proposal was the CAPABILITY reply be extended. Please >read all of the posts before replying with more underinformed comments. > > Please read the post you are replying to before making accusations. I was talking about *all* iCalendar implementations, not just CAP; Bruce responded accordingly. -- /=====================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=====================================================| |"The Reality Check's in the mail." --L. Peter Deutsch| \=====================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 4 14:27:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29604 for ; Tue, 4 Nov 2003 14:27:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JGBkT068357 for ; Tue, 4 Nov 2003 11:16:11 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JGBum068356 for ietf-calendar-bks; Tue, 4 Nov 2003 11:16:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JGAkT068351 for ; Tue, 4 Nov 2003 11:16:10 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA4JG76M018293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Nov 2003 11:16:08 -0800 Message-ID: <3FA7FAF1.2050508@Royer.com> Date: Tue, 04 Nov 2003 12:16:01 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: CAP-VERSION Property References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020304080609070602000306" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020304080609070602000306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/03/2003 04:42:26 PM: > > > 1: Is there a reason CAP-VERSION is not defined like VERSION is in > > > iCalendar? > > > > It is a multivalued field unlike VERSION. So you could say you are RFC > > X, and Z compatible > > skipping Y if needed. > > My appologies for not be more precise in the question. I was > referring to using a numeric values like VERSION (which actually is > biparted): Do you have a proposal? It does not look like it to me. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020304080609070602000306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA0MTkxNjAxWjAjBgkqhkiG9w0BCQQxFgQUYdsTiWd61ea+j7cdOcvV ALVc6twwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAPMrUjp3rWbxYxVzbIFSecsb5qieG0HSsvBmSU58s1uEwqgzkjhUVGsXxls4h4mYT Zzu+1eRNz0g1j8EmUJYav+6QmgUUciSpjEXKi4nWpdFyr95jwHMoa4rmnB2TylKNlOvirzGP vWo1GS27iVso+nG6bQrKGs9JIZf7muOwkmlgRirFCfGNuet5LtXeLs4C//UrXE006uM5Lho3 4PqupoodfkqjyAa1iZnDdnK/4rWQDlKyTiZp33u4tQ/kcXP4TCF6ebppmuGATrhkJJQTaOaG XZ6pu3iP5PJ689PDGGc5juLx26jpPC66ha1ckyQJbS05cgw3lACBj6ObvNFpRwAAAAAAAA== --------------ms020304080609070602000306-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 14:44:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00514 for ; Tue, 4 Nov 2003 14:44:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JR7kT069086 for ; Tue, 4 Nov 2003 11:27:07 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JR7vk069085 for ietf-calendar-bks; Tue, 4 Nov 2003 11:27:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JR5kT069077 for ; Tue, 4 Nov 2003 11:27:05 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA4JR284017440 for ; Tue, 4 Nov 2003 12:27:02 -0700 (MST) Message-ID: <3FA7FD86.A224139B@INET-Calendar.net> Date: Tue, 04 Nov 2003 12:27:02 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar scales References: <3FA7F562.F08156A8@INET-Calendar.net> <3FA7F7BE.8050303@centive.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > > Please read the post you are replying to before making accusations. I > was talking about *all* iCalendar implementations, not just CAP; Bruce > responded accordingly. The original post came from TIM not you, if you wanted to change the subject you should change the SUBJECT line, if you did not (and you did not) then no, TIM was not talking about that. From owner-ietf-calendar@mail.imc.org Tue Nov 4 14:55:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28077 for ; Tue, 4 Nov 2003 14:01:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4In4kT067363 for ; Tue, 4 Nov 2003 10:49:05 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4In4S2067362 for ietf-calendar-bks; Tue, 4 Nov 2003 10:49:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4In3kT067356 for ; Tue, 4 Nov 2003 10:49:03 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA4In084016283 for ; Tue, 4 Nov 2003 11:49:00 -0700 (MST) Message-ID: <3FA7F49C.D0BA5E58@INET-Calendar.net> Date: Tue, 04 Nov 2003 11:49:00 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-e: Alarms and SEQUENCE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 11/03/2003 04:38:17 PM: > > > I claim that this is a non-sensical / practical case to use. > (Plus > > > its the only one I could think of too.) > > > > So in other words - you can't make it work. > > I claim your example is not one thats worth considering because its > non-realistic. So in other words - you can't make it work. From owner-ietf-calendar@mail.imc.org Tue Nov 4 15:15:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29603 for ; Tue, 4 Nov 2003 14:27:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JEVkT068290 for ; Tue, 4 Nov 2003 11:14:31 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4JEVx6068289 for ietf-calendar-bks; Tue, 4 Nov 2003 11:14:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JEUkT068284 for ; Tue, 4 Nov 2003 11:14:30 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA4JEQ6M018247 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Nov 2003 11:14:27 -0800 Message-ID: <3FA7FA8C.4070406@Royer.com> Date: Tue, 04 Nov 2003 12:14:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar scales References: <5.2.1.1.0.20031103205512.00a30b20@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031103205512.00a30b20@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020303000307050108060203" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020303000307050108060203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > > I had in mind more the Hebrew CUA asking the CS if it could use the > Hebrew calendar when storing items; but your examples work as well. I > am still in favor of this small addition to the GET-CAPABILITY return, > since anything that makes things fail more gracefully in my book is a > good thing. > > Tim Hare > Interested Bystander, Non-Inc. I do agree with you. However we are trying to get CAP out and additions or deletions at this point will require (per the AD in S.F.) a huge consensus. It does not look like there has been one for this. I have submitted a couple of CAP add-on (separate) drafts, Adding what you request as an add on may be the way to get it done. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020303000307050108060203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA0MTkxNDIwWjAjBgkqhkiG9w0BCQQxFgQU7AUaDh7skYjq/Iwvt7ay 58qpsQ8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAWefhv8RT0GScdAjdBHILUuohcRTPHUfF5521JwIDY8x9usX8jBC7yo8Pk5WIvXqp nP8wQ6PjuB+gEOqK37eUmttJ3AhUyC6RPsR2Wkbs6KO8sYwH9ntLKdwNVkl9Lu7VgeLNdelb RBFb4diAIbLxmXhndRTqvHrRsh8XmZbhE71SjJPcutRrfKFMUZLxNVhX8SdDfHgKLm+i+huH BZXvDt3RezXt4LUA88ae83tGcKAzuYg9ytpHluTSV4bYqQfrG8Scm+bjvT0Q377pyduA6SNz WwcSzLsanq99/JllLhkM+kBw75WxwP02cwfDHI7axZMKydQieixlESUNRZqWPAAAAAAAAA== --------------ms020303000307050108060203-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 16:56:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07524 for ; Tue, 4 Nov 2003 16:56:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LBekT072843 for ; Tue, 4 Nov 2003 13:11:40 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4LBeY4072842 for ietf-calendar-bks; Tue, 4 Nov 2003 13:11:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LBdkT072837 for ; Tue, 4 Nov 2003 13:11:39 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA4LBY6M020403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Nov 2003 13:11:38 -0800 Message-ID: <3FA81601.3050205@Royer.com> Date: Tue, 04 Nov 2003 14:11:29 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: EXPAND property: All instances? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000503030905000103000109" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000503030905000103000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I have a simple question regarding the EXPAND property. In CAP-12-e > it is described as: > > Description: If a CUA wishes to see all of the instances of a > recurring component the CUA sets EXPAND=TRUE in the "VQUERY" > component. If not specified, the default is FALSE. Note that if the > CS has its "RECUR-EXPAND" CS property value set to false then the > "EXPAND" property will be ignored and the result will be as if the > "EXPAND" value was set to false. > > My question is simply this: Is the CS supposed to return literally > all instances of a repeating entry even if they fall outside the > bounds of the parameters in the VQUERY? I assume you mean - you want the text fixed? Or are you really confused? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000503030905000103000109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA0MjExMTI5WjAjBgkqhkiG9w0BCQQxFgQU54WxC7GNNJy6m7flcJmo ATULiLEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEADPirHAro9GHkC3Tmuum1zhNrxIs0T4lNhutWCq+WSfO+P41siWzvG9zhD4gU1u6y 1l8yUjO8Of0Qws6Z7D7Qm8th5ScTUuDdam0w+iwgYtKJecERMuTGm3UrY9duGoOZzBN1+rtw Zha3WFtSNoj6QVBL6Jv7GtPfdYsZvlXVqsP5OJACKVO/+OeW72q7sFevVMXjHd7S9p5bgDI2 v7RGxcdxmu4ONXxzEqCi9BeGAsX/5Dss/ITIaaiCksiia+UKsbaOlPh7Dy4N1mFNzAPSDvWX jjBL7/B+Hd6LHgKlOn55vRzmgP/cdyWwQxOM0Nehsw765NvaCBZop1Jl6x5/FwAAAAAAAA== --------------ms000503030905000103000109-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 17:22:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08821 for ; Tue, 4 Nov 2003 17:22:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LfPkT073611 for ; Tue, 4 Nov 2003 13:41:25 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4LfOEQ073610 for ietf-calendar-bks; Tue, 4 Nov 2003 13:41:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4LfNkT073600 for ; Tue, 4 Nov 2003 13:41:23 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FA7F562.F08156A8@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: different calendar scales MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Nov 2003 16:41:28 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/04/2003 04:41:25 PM, Serialize complete at 11/04/2003 04:41:25 PM Content-Type: multipart/alternative; boundary="=_alternative 0077273585256DD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077273585256DD4_= Content-Type: text/plain; charset="US-ASCII" As I have said before, everyone, including you, Mr. Smith, should respond to this list with constructive comments only. I'm really very tired of the way this list has turned into a series of nastygrams. I continue to get private notes from people saying they no longer particpate on the list because of the tone of many of the notes. Therefore, I want everyone - Doug, Mark, Bruce - everyone - to keep notes to calendaring topics. If it continues, I will go back to the IETF management and ask them to remove people from our lists. That's a promise. Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 11/04/2003 13:52 To ietf-calendar@imc.org cc Subject Re: different calendar scales Bruce_Kahn@notesdev.ibm.com wrote: > > John replied on 11/03/2003 04:17:52 PM: > > I think, if we ever get non-Gregorian scales, we'll have to mandate > that > > all iCalendar implementations support Gregorian, for interop with > > existing implementations. > > That defeats the purpose of having CALSCALE in the entity doesnt it? The original proposal was the CAPABILITY reply be extended. Please read all of the posts before replying with more underinformed comments. --=_alternative 0077273585256DD4_= Content-Type: text/html; charset="US-ASCII"
As I have said before, everyone, including you, Mr. Smith, should respond to this list with constructive comments only.  I'm really very tired of the way this list has turned into a series of nastygrams.  I continue to get private notes from people saying they no longer particpate on the list because of the tone of many of the notes.  Therefore, I want everyone - Doug, Mark, Bruce - everyone - to keep notes to calendaring topics.  If it continues, I will go back to the IETF management and ask them to remove people from our lists.  That's a promise.



Mark Smith <mark@inet-calendar.net>
Sent by: owner-ietf-calendar@mail.imc.org

11/04/2003 13:52

To
ietf-calendar@imc.org
cc
Subject
Re: different calendar scales






Bruce_Kahn@notesdev.ibm.com wrote:
>
> John replied on 11/03/2003 04:17:52 PM:
> > I think, if we ever get non-Gregorian scales, we'll have to mandate
> that
> > all iCalendar implementations support Gregorian, for interop with
> > existing implementations.
>
> That defeats the purpose of having CALSCALE in the entity doesnt it?

The original proposal was the CAPABILITY reply be extended. Please
read all of the posts before replying with more underinformed comments.
--=_alternative 0077273585256DD4_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 17:43:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09397 for ; Tue, 4 Nov 2003 17:43:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4M2HkT074430 for ; Tue, 4 Nov 2003 14:02:17 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4M2HxH074429 for ietf-calendar-bks; Tue, 4 Nov 2003 14:02:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4M2FkT074424 for ; Tue, 4 Nov 2003 14:02:15 -0800 (PST) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Status of the CALSCH working group MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Nov 2003 17:02:24 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/04/2003 05:02:18 PM, Serialize complete at 11/04/2003 05:02:18 PM Content-Type: multipart/alternative; boundary="=_alternative 0079120F85256DD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079120F85256DD4_= Content-Type: text/plain; charset="US-ASCII" I have been, like I am sure everyone else, trying to keep up with the deluge of mail, particularly from Doug. I think the approach of flooding inbaskets with emails challenging comments regarding the CAP draft has proven to be a bad one. I pulled over 48,000 emails into a tool to try to glean out where we reached consensus (the few times that we did). I also did this to come up with an issues list. In the past, this was either kept by the chair or by the editor. Since this has not been done by either, I felt I needed to come up with something. However, it has turned into a much bigger problem that I first anticipated. The subject line of the note is not enough to determine the bodies of the emails. Some of the emails have reached "epic" proportions and have as many as 10 subjects embedded in the note. It's no wonder that we can't get consensus or even determine if we have reached a point where we are close. Several months ago I attempted to put a last call out on CAP. At that point, enough noise was generated on the list to prove to me that CAP in it's current status is not ready for prime time. And, based on what I am seeing on the list, when someone makes a point that a section or item is wrong on the list, we don't get closure or a different solution. We get instead a rash of emails that make it impossible to keep up with the thread or topic. We then also start to see the derogatory remarks instead of constructive criticism. That being said, I know I don't have the time to manage this nor does anyone else. If we were getting constructive dialogs then I would say yes. At this juncture, all we are doing is spinning our wheels. Our deadlines for CAP are all overdue. CAP as it stands is not ready for prime time. So, at the Minneapolis meeting I am going to propose that we close down the working group and put it on hiatus until such time as we have something that can be submitted that meets everyone's needs - and not just those of a few people. There are changes that need to be made to iCalendar, iTIP and iMIP to match what we have found in interop testing. All of these can be put into new drafts and submitted privately to the IETF. Most of the changes are areas that simply do not work - when submitted, they will not break interoperability, they will ensure it. It will then become the responsibility of the Method Reviewer to validate that the changes are done. This does not require a working group to submit these changes. If anyone feels I am wrong in closing the group, they are welcome to discuss it with the Area Directors at the Minneapolis meeting. --=_alternative 0079120F85256DD4_= Content-Type: text/html; charset="US-ASCII"
I have been, like I am sure everyone else, trying to keep up with the deluge of mail, particularly from Doug.  I think the approach of flooding inbaskets with emails challenging comments regarding the CAP draft has proven to be a bad one.

I pulled over 48,000 emails into a tool to try to glean out where we reached consensus (the few times that we did).  I also did this to come up with an issues list.  In the past, this was either kept by the chair or by the editor.  Since this has not been done by either, I felt I needed to come up with something.

However, it has turned into a much bigger problem that I first anticipated.  The subject line of the note is not enough to determine the bodies of the emails.  Some of the emails have reached "epic" proportions and have as many as 10 subjects embedded in the note.  It's no wonder that we can't get consensus or even determine if we have reached a point where we are close.

Several months ago I attempted to put a last call out on CAP.  At that point, enough noise was generated on the list to prove to me that CAP in it's current status is not ready for prime time.  And, based on what I am seeing on the list, when someone makes a point that a section or item is wrong on the list, we don't get closure or a different solution.  We get instead a rash of emails that make it impossible to keep up with the thread or topic.  We then also start to see the derogatory remarks instead of constructive criticism.

That being said, I know I don't have the time to manage this nor does anyone else.  If we were getting constructive dialogs then I would say yes.  At this juncture, all we are doing is spinning our wheels.

Our deadlines for CAP are all overdue.  CAP as it stands is not ready for prime time.

So, at the Minneapolis meeting I am going to propose that we close down the working group and put it on hiatus until such time as we have something that can be submitted that meets everyone's needs - and not just those of a few people.  There are changes that need to be made to iCalendar, iTIP and iMIP to match what we have found in interop testing.  All of these can be put into new drafts and submitted privately to the IETF.  Most of the changes are areas that simply do not work - when submitted, they will not break interoperability, they will ensure it.  It will then become the responsibility of the Method Reviewer to validate that the changes are done.  This does not require a working group to submit these changes.

If anyone feels I am wrong in closing the group, they are welcome to discuss it with the Area Directors at the Minneapolis meeting.

--=_alternative 0079120F85256DD4_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 19:02:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12290 for ; Tue, 4 Nov 2003 19:02:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NjvkT077720 for ; Tue, 4 Nov 2003 15:45:57 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4NjvOV077719 for ietf-calendar-bks; Tue, 4 Nov 2003 15:45:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NjtkT077713 for ; Tue, 4 Nov 2003 15:45:55 -0800 (PST) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Recurrence-ID issue - Comments from the original authors MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Nov 2003 18:46:05 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/04/2003 06:45:58 PM, Serialize complete at 11/04/2003 06:45:58 PM Content-Type: multipart/alternative; boundary="=_alternative 00828FE985256DD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00828FE985256DD4_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Several months ago, I approached the original authors of iTIP to raise the = issues of Recurrence IDs. They have, in their busy schedules, come up=20 with some points/comments. I am posting them to the list with their=20 permission. From Frank Dawson and Derik Stenerson: "We understand that there was a question of interpretation about whether=20 the value for the RECURRENCE-ID property for a recurrence instance will=20 change when the recurrence instance start/end date/time is modified. We have read through related email threads about the discussions on this=20 matter and have reviewed relevant sections of the RFC2445/iCalendar and=20 RFC2446/iTIP. Our opinion is that: 1) The issue resides with interpretation of the semantics and behavior of = a property for an iCalendar component; which is defined by=20 RFC2445/iCalendar alone. 2) The RFC2445/iCalendar is the foundation for the suite of IETF=20 calendaring/scheduling RFCs. The purpose of this specification is to=20 define the common semantics and behavior for calendar components,=20 properties and parameters utilized by the companion specifications (i.e., = RFCs 2446 and 2447). These companion specifications were never intended=20 to be inconsistent from or overriding of the semantics and behavior=20 defined by RFC2445. 3) Considerable discussion was held on semantics and behavior of recurring = events during the IETF deliberations leading to WG consensus around the=20 definition of iCalendar. It is our belief that the intent of this=20 consensus is as follows:=20 a) the value for RECURRENCE-ID was agreed to be the date/time value of=20 the original recurrence instance. This value remains unchanged for as long = as the base recurrence set (or pattern) exists. A rescheduling of an=20 individual recurrence instance did not cause creation of new base=20 recurrence set, but only moved the start/end of the specified recurrence=20 instance.=20 b) An addition of a new recurrence instance to the set would be an example = of an action that would create a new recurrence set ? e.g. changing a=20 Monday weekly meeting to a Monday and Tuesday weekly meeting. This latter=20 action is an example of an action that *might* also cause the values of=20 the RECURRENCE-ID properties for each member of the recurrence set to get = redefined (*might* is used here and in the RFC because it is possible=20 that occurrences in the new recurrence set will have the same date/time=20 value). But a rescheduling of a member of the recurrence set would not=20 cause such behavior (i.e., change the value) of the RECURRENCE-ID=20 property associated with the rescheduled recurrence instance.=20 This semantic and behavior was settled on because it is imperative in=20 order for an implementation to maintain order and sensibility between the = original definition for the recurrence set and exceptions created by=20 subsequent rescheduling actions on the recurrence set.=20 To illustrate, consider the consequences if RECURRENCE-ID changed on each = reschedule of an instance. Specifically, if the RECURRENCE-ID is changed=20 on each reschedule of an instance, the sender and the recipient have no=20 way to accurately know which instance is being referred to if just a=20 single iTIP message was lost or mis-sequenced, or if the message is an=20 invitation to a new instance entirely. This inability to distinguish=20 invitation, from reschedule, from update is not problematic with the=20 fixed RECURRENCE-ID because it is unambiguous which instance is being=20 referred to.=20 Both of us remember numerous such use cases being presented to illustrate = the conditions and border-cases for such changes to the original=20 recurrence instances and the recurrence set. 4) It is worth noting that those discussion in the related WG email=20 threads referring to examples in iTIP are problematic, as section 3 of=20 RFC2446 was intended to be illustrative text and was not reviewed as=20 thoroughly as other sections of the RFC for consistency with iCalendar=20 semantics or conformity to iTIP normative sections. This text defines a=20 set of examples, or informational material. Further, this text is known=20 to have numerous typographic errors. 5) It is also worth noting that the semantics and behavior confirmed in=20 (3), above, is validated by existing deployed calendaring/scheduling=20 systems. A different interpretation of the semantics and behavior would=20 be counter to this practice today.=20 In summary, the original intention of the iCalendar specification was=20 that the value of the RECURRENCE-ID for a specific recurrence instance=20 would remain unchanged for the duration of the existence of the=20 recurrence set. Rescheduling individual recurrence instances did not=20 cause recreation of the recurrence set or change the value of the=20 RECURRENCE-ID property for the associated recurrence instance, but only=20 involved changes to the start/end of the recurrence instance. Frank Dawson and Derik Stenerson" --=_alternative 00828FE985256DD4_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Several months ago, I approached the original authors of iTIP to raise the issues of Recurrence IDs.  They have, in their busy schedules, come up with some points/comments.  I am posting them to the list with their permission.

From Frank Dawson and Derik Stenerson:

"We understand that there was a question of  i= nterpretation about whether the value for the RECURRENCE-ID property for a  recurren= ce instance will change when the recurrence instance start/end date/time  = ;is modified.

We have read through related email threads about the dis= cussions  on this matter and have reviewed relevant sections of the RFC2445/iCa= lendar and  RFC2446/iTIP.

Our opinion is that:

1) The issue resides with interpretation of the semantics and  behavior of a property for an iCalendar component; which is defin= ed by  RFC2445/iCalendar alone.

2) The RFC2445/iCalendar is the foundation for the suite of IETF  calendaring/scheduling RFCs. The purpose of this specification is to define the  common semantics and behavior for calendar component= s, properties and parameters  utilized by the companion specifications (i.e., RFCs 2446 and 2447). These  companion specifications were never intended to be inconsistent from or overriding of the semantics and behavior defined by RFC2445.

3) Considerable discussion was held on semantics and beh= avior of  recurring events during the IETF deliberations leading to WG conse= nsus around  the definition of iCalendar. It is our belief that the intent of this consensus  is as follows:

a) the value for RECURRENCE-ID was agreed to be the date= /time  value of the original recurrence instance. This value remains unchang= ed for as  long as the base recurrence set (or pattern) exists. A resched= uling of an  individual recurrence instance did not cause creation of new base recurrence  set, but only moved the start/end of the specified recurrence instance.  

b) An addition of a new recurrence instance to the set would be an  example of an action that would create a new recurrence set – e.g. changing a  Monday weekly meeting to a Monday and Tue= sday weekly meeting. This latter action  is an example of an action that *might* also cause the values of the  RECURRENCE-ID properties for each member of the recurrence set to get redefined  (*might* is used here and in the RFC because it is possible that occurrences in  the new recurrence set will have the same date/time value). But a rescheduling  of a member of the recurrence set would not cause such behavior (i.e., change  the value) of the RECURRENCE-ID property associated with the rescheduled  recurrence instance.

This semantic and behavior was settled on because it is imperative in order for  an implementation to maintain order and sensi= bility between the original definition  for the recurrence set and exceptions created by subsequent rescheduling actions  on the recurrence set.

To illustrate, consider the consequences if RECURRENCE-ID  changed on each reschedule of an instance. Specifically, if the RECUR= RENCE-ID is  changed on each reschedule of an instance, the sender and the recipient have no  way to accurately know which instance is being referred to if just a single iTIP  message was lost or mis-sequenced, or if the message is an invitation to a new  instance entirely.  This inability  to distinguish invitation, from reschedule, from update is not problematic with  the fixed RECURRENCE-ID because it is unambig= uous which instance is being  referred to.

Both of us remember numerous such use cases being presen= ted to  illustrate the conditions and border-cases for such changes to the original  recurrence instances and the recurrence set.

4) It is worth noting that those discussion in the relat= ed WG  email threads referring to examples in iTIP are problematic, as section 3 of  RFC2446 was intended to be illustrative text and was not reviewed as thoroughly  as other sections of the RFC for consisten= cy with iCalendar semantics or  conformity to iTIP normative sections. This text defines a set of examples, or  informational material. Furth= er, this text is known to have numerous typographic  errors.

 5) It is also worth noting that the semantics and  behavior confirmed in (3), above, is validated by existing  depl= oyed calendaring/scheduling systems. A different interpretation of the semantics  and behavior would be counter to this practice today.


In summary, the original intention of the iCalendar spec= ification  was that the value of the RECURRENCE-ID for a specific recurrence instance would  remain unchanged for the duration of the existence of the recurrence set.  Rescheduling individual recurrence instances did not cause recreation of the  recurrence set or change the value of the RECURRENCE-ID property for the  associated recurrence instance, but only involved changes to the start/end of  the recurrence instance= .

Frank Dawson and Derik Stenerson" --=_alternative 00828FE985256DD4_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 19:03:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12347 for ; Tue, 4 Nov 2003 19:03:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4Na5kT077444 for ; Tue, 4 Nov 2003 15:36:05 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4Na5dG077443 for ietf-calendar-bks; Tue, 4 Nov 2003 15:36:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4Na3kT077427 for ; Tue, 4 Nov 2003 15:36:03 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA4NZv84025284; Tue, 4 Nov 2003 16:35:57 -0700 (MST) Message-ID: <3FA837DD.2BB2BE45@INET-Calendar.net> Date: Tue, 04 Nov 2003 16:35:57 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ned.freed@mrochek.com, hardie@quailcomm.com.cnri.reston.va.us Subject: Re: different calendar scales References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > As I have said before, everyone, including you, Mr. Smith, should > respond to this list with constructive comments only. I'm really very > tired of the way this list has turned into a series of nastygrams. I > continue to get private notes from people saying they no longer > particpate on the list because of the tone of many of the notes. > Therefore, I want everyone - Doug, Mark, Bruce - everyone - to keep > notes to calendaring topics. If it continues, I will go back to the > IETF management and ask them to remove people from our lists. That's > a promise. Remove me if you want, but Bruce's inaccurate posts and your lack of willingness to act is killing CAP. You let him ramble on and on and on about items that have been in the draft for years without ever calling consensus. That's not Bruce's or Doug's fault - please act. You seem to be unwilling or unable to make technical decisions. Just because Bruce posts does not mean that he is right or accurate. He almost never posts a proposal and almost never responds to questions and declares that others misunderstand him. And you seem to be unwilling or unable to notice. You asked me in private email if I worked for Doug which I found insulting. Do you work for Bruce or are you affiliated with Bruce or his company? What is you motive for allowing Bruce to post inaccurate information over and over again and then complain when someone calls Bruce on it? Looking over the archives I can only find a small handful of times that you called consensus on anything. No wonder CAP is not finished. Doug send me private email about a commercial calendar consortium that you and someone else are forming wanting to know if I knew or wanted to participate (as Doug's company runs our calendar servers). Is that your motive for not acting on CAP? Did you bother telling this list that you have commercial motives that may keep you from being impartial? From owner-ietf-calendar@mail.imc.org Tue Nov 4 19:21:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12741 for ; Tue, 4 Nov 2003 19:21:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA506TkT078449 for ; Tue, 4 Nov 2003 16:06:29 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA506TPw078448 for ietf-calendar-bks; Tue, 4 Nov 2003 16:06:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA506SkT078442 for ; Tue, 4 Nov 2003 16:06:28 -0800 (PST) (envelope-from satyanarayana.vempati@Sun.COM) Received: from phys-ha13sca-1 ([129.145.155.91]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA506OPj015823 for ; Tue, 4 Nov 2003 17:06:30 -0700 (MST) Received: from pranav (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HNU00G01QYO6Y@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Tue, 04 Nov 2003 16:06:24 -0800 (PST) Date: Tue, 04 Nov 2003 16:06:30 -0800 From: Satya Vempati Subject: RE: Status of the CALSCH working group In-reply-to: To: pregen@egenconsulting.com, ietf-calendar@imc.org Message-id: <000401c3a330$aa445af0$6d9012c0@red.iplanet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3A2ED.9C211AF0" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C3A2ED.9C211AF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Would it be possible to get someone like Nathaniel Borenstein to take the role of a co-editor (if he is interested)? It would help to have a seasoned veteran of the IETF process to help move things forward. -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of pregen@egenconsulting.com Sent: Tuesday, November 04, 2003 2:02 PM To: ietf-calendar@imc.org Subject: Status of the CALSCH working group I have been, like I am sure everyone else, trying to keep up with the deluge of mail, particularly from Doug. I think the approach of flooding inbaskets with emails challenging comments regarding the CAP draft has proven to be a bad one. I pulled over 48,000 emails into a tool to try to glean out where we reached consensus (the few times that we did). I also did this to come up with an issues list. In the past, this was either kept by the chair or by the editor. Since this has not been done by either, I felt I needed to come up with something. However, it has turned into a much bigger problem that I first anticipated. The subject line of the note is not enough to determine the bodies of the emails. Some of the emails have reached "epic" proportions and have as many as 10 subjects embedded in the note. It's no wonder that we can't get consensus or even determine if we have reached a point where we are close. Several months ago I attempted to put a last call out on CAP. At that point, enough noise was generated on the list to prove to me that CAP in it's current status is not ready for prime time. And, based on what I am seeing on the list, when someone makes a point that a section or item is wrong on the list, we don't get closure or a different solution. We get instead a rash of emails that make it impossible to keep up with the thread or topic. We then also start to see the derogatory remarks instead of constructive criticism. That being said, I know I don't have the time to manage this nor does anyone else. If we were getting constructive dialogs then I would say yes. At this juncture, all we are doing is spinning our wheels. Our deadlines for CAP are all overdue. CAP as it stands is not ready for prime time. So, at the Minneapolis meeting I am going to propose that we close down the working group and put it on hiatus until such time as we have something that can be submitted that meets everyone's needs - and not just those of a few people. There are changes that need to be made to iCalendar, iTIP and iMIP to match what we have found in interop testing. All of these can be put into new drafts and submitted privately to the IETF. Most of the changes are areas that simply do not work - when submitted, they will not break interoperability, they will ensure it. It will then become the responsibility of the Method Reviewer to validate that the changes are done. This does not require a working group to submit these changes. If anyone feels I am wrong in closing the group, they are welcome to discuss it with the Area Directors at the Minneapolis meeting. ------=_NextPart_000_0005_01C3A2ED.9C211AF0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Would it be possible to get someone = like Nathaniel Borenstein to take the role of a co-editor (if he is = interested)? It would help to have a seasoned veteran of the IETF process to help move = things forward.

 

-----Original = Message-----
From: owner-ietf-calendar@mail.imc.org = [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of = pregen@egenconsulting.com
Sent: Tuesday, November = 04, 2003 2:02 PM
To: = ietf-calendar@imc.org
Subject: Status of the = CALSCH working group

 


I have been, like I am sure everyone else, = trying to keep up with the deluge of mail, particularly from Doug.  I think = the approach of flooding inbaskets with emails challenging comments = regarding the CAP draft has proven to be a bad one.

I pulled over 48,000 emails into a tool to try to glean out where we = reached consensus (the few times that we did).  I also did this to come up = with an issues list.  In the past, this was either kept by the chair or by = the editor.  Since this has not been done by either, I felt I needed to = come up with something.

However, it has turned into a much bigger problem that I first anticipated. =  The subject line of the note is not enough to determine the bodies of the = emails.  Some of the emails have reached "epic" proportions and have as many = as 10 subjects embedded in the note.  It's no wonder that we can't get = consensus or even determine if we have reached a point where we are = close.

Several months ago I attempted to put a last call out on CAP.  At that = point, enough noise was generated on the list to prove to me that CAP in it's = current status is not ready for prime time.  And, based on what I am seeing = on the list, when someone makes a point that a section or item is wrong on the = list, we don't get closure or a different solution.  We get instead a = rash of emails that make it impossible to keep up with the thread or topic. =  We then also start to see the derogatory remarks instead of constructive criticism.

That being said, I know I don't have the time to manage this nor does anyone = else.  If we were getting constructive dialogs then I would say yes.  At this juncture, all we are doing is spinning our wheels.

Our deadlines for CAP are all overdue.  CAP as it stands is not ready = for prime time.

So, at the Minneapolis meeting I am going to propose that we close down the = working group and put it on hiatus until such time as we have something that can = be submitted that meets everyone's needs - and not just those of a few = people.  There are changes that need to be made to iCalendar, iTIP and iMIP to match = what we have found in interop testing.  All of these can be put into new = drafts and submitted privately to the IETF.  Most of the changes are areas = that simply do not work - when submitted, they will not break = interoperability, they will ensure it.  It will then become the responsibility of the = Method Reviewer to validate that the changes are done.  This does not = require a working group to submit these changes.

If anyone feels I am wrong in closing the group, they are welcome to = discuss it with the Area Directors at the Minneapolis meeting.

------=_NextPart_000_0005_01C3A2ED.9C211AF0-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 19:38:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13336 for ; Tue, 4 Nov 2003 19:38:53 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50PHkT079404 for ; Tue, 4 Nov 2003 16:25:17 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA50PGeT079403 for ietf-calendar-bks; Tue, 4 Nov 2003 16:25:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50PEkT079397 for ; Tue, 4 Nov 2003 16:25:15 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <000401c3a330$aa445af0$6d9012c0@red.iplanet.com> To: Satya Vempati Cc: ietf-calendar@imc.org Subject: RE: Status of the CALSCH working group MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Nov 2003 19:25:24 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/04/2003 07:25:17 PM, Serialize complete at 11/04/2003 07:25:17 PM Content-Type: multipart/alternative; boundary="=_alternative 000253BD85256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000253BD85256DD5_= Content-Type: text/plain; charset="US-ASCII" Hm, interesting idea. Satya Vempati 11/04/2003 19:06 To pregen@egenconsulting.com, ietf-calendar@imc.org cc Subject RE: Status of the CALSCH working group Would it be possible to get someone like Nathaniel Borenstein to take the role of a co-editor (if he is interested)? It would help to have a seasoned veteran of the IETF process to help move things forward. -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of pregen@egenconsulting.com Sent: Tuesday, November 04, 2003 2:02 PM To: ietf-calendar@imc.org Subject: Status of the CALSCH working group I have been, like I am sure everyone else, trying to keep up with the deluge of mail, particularly from Doug. I think the approach of flooding inbaskets with emails challenging comments regarding the CAP draft has proven to be a bad one. I pulled over 48,000 emails into a tool to try to glean out where we reached consensus (the few times that we did). I also did this to come up with an issues list. In the past, this was either kept by the chair or by the editor. Since this has not been done by either, I felt I needed to come up with something. However, it has turned into a much bigger problem that I first anticipated. The subject line of the note is not enough to determine the bodies of the emails. Some of the emails have reached "epic" proportions and have as many as 10 subjects embedded in the note. It's no wonder that we can't get consensus or even determine if we have reached a point where we are close. Several months ago I attempted to put a last call out on CAP. At that point, enough noise was generated on the list to prove to me that CAP in it's current status is not ready for prime time. And, based on what I am seeing on the list, when someone makes a point that a section or item is wrong on the list, we don't get closure or a different solution. We get instead a rash of emails that make it impossible to keep up with the thread or topic. We then also start to see the derogatory remarks instead of constructive criticism. That being said, I know I don't have the time to manage this nor does anyone else. If we were getting constructive dialogs then I would say yes. At this juncture, all we are doing is spinning our wheels. Our deadlines for CAP are all overdue. CAP as it stands is not ready for prime time. So, at the Minneapolis meeting I am going to propose that we close down the working group and put it on hiatus until such time as we have something that can be submitted that meets everyone's needs - and not just those of a few people. There are changes that need to be made to iCalendar, iTIP and iMIP to match what we have found in interop testing. All of these can be put into new drafts and submitted privately to the IETF. Most of the changes are areas that simply do not work - when submitted, they will not break interoperability, they will ensure it. It will then become the responsibility of the Method Reviewer to validate that the changes are done. This does not require a working group to submit these changes. If anyone feels I am wrong in closing the group, they are welcome to discuss it with the Area Directors at the Minneapolis meeting. --=_alternative 000253BD85256DD5_= Content-Type: text/html; charset="US-ASCII"
Hm, interesting idea.


Satya Vempati <satyanarayana.vempati@Sun.COM>

11/04/2003 19:06

To
pregen@egenconsulting.com, ietf-calendar@imc.org
cc
Subject
RE: Status of the CALSCH working group





Would it be possible to get someone like Nathaniel Borenstein to take the role of a co-editor (if he is interested)? It would help to have a seasoned veteran of the IETF process to help move things forward.
 
-----Original Message-----
From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of pregen@egenconsulting.com
Sent: Tuesday, November 04, 2003 2:02 PM
To: ietf-calendar@imc.org
Subject: Status of the CALSCH working group
 

I have been, like I am sure everyone else, trying to keep up with the deluge of mail, particularly from Doug.  I think the approach of flooding inbaskets with emails challenging comments regarding the CAP draft has proven to be a bad one.

I pulled over 48,000 emails into a tool to try to glean out where we reached consensus (the few times that we did).  I also did this to come up with an issues list.  In the past, this was either kept by the chair or by the editor.  Since this has not been done by either, I felt I needed to come up with something.

However, it has turned into a much bigger problem that I first anticipated.  The subject line of the note is not enough to determine the bodies of the emails.  Some of the emails have reached "epic" proportions and have as many as 10 subjects embedded in the note.  It's no wonder that we can't get consensus or even determine if we have reached a point where we are close.

Several months ago I attempted to put a last call out on CAP.  At that point, enough noise was generated on the list to prove to me that CAP in it's current status is not ready for prime time.  And, based on what I am seeing on the list, when someone makes a point that a section or item is wrong on the list, we don't get closure or a different solution.  We get instead a rash of emails that make it impossible to keep up with the thread or topic.  We then also start to see the derogatory remarks instead of constructive criticism.

That being said, I know I don't have the time to manage this nor does anyone else.  If we were getting constructive dialogs then I would say yes.  At this juncture, all we are doing is spinning our wheels.

Our deadlines for CAP are all overdue.  CAP as it stands is not ready for prime time.

So, at the Minneapolis meeting I am going to propose that we close down the working group and put it on hiatus until such time as we have something that can be submitted that meets everyone's needs - and not just those of a few people.  There are changes that need to be made to iCalendar, iTIP and iMIP to match what we have found in interop testing.  All of these can be put into new drafts and submitted privately to the IETF.  Most of the changes are areas that simply do not work - when submitted, they will not break interoperability, they will ensure it.  It will then become the responsibility of the Method Reviewer to validate that the changes are done.  This does not require a working group to submit these changes.

If anyone feels I am wrong in closing the group, they are welcome to discuss it with the Area Directors at the Minneapolis meeting.
--=_alternative 000253BD85256DD5_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 19:56:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13688 for ; Tue, 4 Nov 2003 19:56:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50ackT079950 for ; Tue, 4 Nov 2003 16:36:38 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA50aco6079949 for ietf-calendar-bks; Tue, 4 Nov 2003 16:36:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50aZkT079933 for ; Tue, 4 Nov 2003 16:36:35 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FA837DD.2BB2BE45@INET-Calendar.net> To: Mark Smith Cc: hardie@quailcomm.com.cnri.reston.va.us, ietf-calendar@imc.org, ned.freed@mrochek.com, owner-ietf-calendar@mail.imc.org Subject: Re: different calendar scales MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Nov 2003 19:36:41 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/04/2003 07:36:38 PM, Serialize complete at 11/04/2003 07:36:38 PM Content-Type: multipart/alternative; boundary="=_alternative 00035C3085256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00035C3085256DD5_= Content-Type: text/plain; charset="US-ASCII" I expected that my note would not be popular. I'm not going to respond to all your items because it's not worth my time nor the lists. I too went back to try to find concensus - and responded to the list the very few times we had any at all. I too have felt I wasn't doing much - but then, I have been assured in private emails, there hasn't been much to respond to in the way of concensus. Believe me, I will lay blame on myself before anyone, so as yourself will do so. That's my style - up front and honest. Regarding the consortium, this is not a secret. it was announced publically at an IETF over a year and a half ago. The consortium is a non-profit organization - not a commercial one. I am not going to be the person running it. It is my brainchild as an effort to get calendaring and scheduling into the limelight and give recognition to organizations that have calendaring products and to give information to those people looking for calendaring products as well. We also hope to host the interoperability tests and provide an even better mechanism for this. It is not, nor has it been the intention, of the consortium to go against the IETF work. In fact, it is meant to be a continuation of the efforts. At least two IETF meetings ago, the Area Directors asked us to make efforts to close up the working group. I asked for more time so we could make changes to the three RFC's and to get CAP out the door. That's when I placed the last call. Everyone knows what happened next. With regards to insulting, I believe your last paragraph is the most insulting of all. No, I am not endorsing the consortium for commerical reasons. I will not get monies from the organization. I will not get recognition. I expect to provide hard work, my time, my efforts, all towards getting calendaring somewhere other than in the dark ages. As for asking you if you worked for Doug, it was not meant to be insulting. I saw your email id and saw that it was the same domain as Doug's. It was a curious question - not an insulting one. I believe when I asked you that question, it was also at the same time I privately asked you to not be so offensive on the list. That request, apparently, was not heeded. Again, yet another reason it's probably time to close down the working group. Or, better yet, get another, tougher skinned, working group chair. Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 11/04/2003 18:35 To ietf-calendar@imc.org cc ned.freed@mrochek.com, hardie@quailcomm.com Subject Re: different calendar scales pregen@egenconsulting.com wrote: > > As I have said before, everyone, including you, Mr. Smith, should > respond to this list with constructive comments only. I'm really very > tired of the way this list has turned into a series of nastygrams. I > continue to get private notes from people saying they no longer > particpate on the list because of the tone of many of the notes. > Therefore, I want everyone - Doug, Mark, Bruce - everyone - to keep > notes to calendaring topics. If it continues, I will go back to the > IETF management and ask them to remove people from our lists. That's > a promise. Remove me if you want, but Bruce's inaccurate posts and your lack of willingness to act is killing CAP. You let him ramble on and on and on about items that have been in the draft for years without ever calling consensus. That's not Bruce's or Doug's fault - please act. You seem to be unwilling or unable to make technical decisions. Just because Bruce posts does not mean that he is right or accurate. He almost never posts a proposal and almost never responds to questions and declares that others misunderstand him. And you seem to be unwilling or unable to notice. You asked me in private email if I worked for Doug which I found insulting. Do you work for Bruce or are you affiliated with Bruce or his company? What is you motive for allowing Bruce to post inaccurate information over and over again and then complain when someone calls Bruce on it? Looking over the archives I can only find a small handful of times that you called consensus on anything. No wonder CAP is not finished. Doug send me private email about a commercial calendar consortium that you and someone else are forming wanting to know if I knew or wanted to participate (as Doug's company runs our calendar servers). Is that your motive for not acting on CAP? Did you bother telling this list that you have commercial motives that may keep you from being impartial? --=_alternative 00035C3085256DD5_= Content-Type: text/html; charset="US-ASCII"
I expected that my note would not be popular.  I'm not going to respond to all your items because it's not worth my time nor the lists.  I too went back to try to find concensus - and responded to the list the very few times we had any at all.  I too have felt I wasn't doing much - but then, I have been assured in private emails, there hasn't been much to respond to in the way of concensus.  Believe me, I will lay blame on myself before anyone, so as yourself will do so.  That's my style - up front and honest.

Regarding the consortium, this is not a secret.  it was announced publically at an IETF over a year and a half ago.  The consortium is a non-profit organization - not a commercial one.  I am not going to be the person running it.  It is my brainchild as an effort to get calendaring and scheduling into the limelight and give recognition to organizations that have calendaring products and to give information to those people looking for calendaring products as well.  We also hope to host the interoperability tests and provide an even better mechanism for this.  It is not, nor has it been the intention, of the consortium to go against the IETF work.  In fact, it is meant to be a continuation of the efforts.

At least two IETF meetings ago, the Area Directors asked us to make efforts to close up the working group.  I asked for more time so we could make changes to the three RFC's and to get CAP out the door.  That's when I placed the last call.  Everyone knows what happened next.

With regards to insulting, I believe your last paragraph is the most insulting of all.  No, I am not endorsing the consortium for commerical reasons.  I will not get monies from the organization.  I will not get recognition.  I expect to provide hard work, my time, my efforts, all towards getting calendaring somewhere other than in the dark ages.

As for asking you if you worked for Doug, it was not meant to be insulting.  I saw your email id and saw that it was the same domain as Doug's.  It was a curious question - not an insulting one.  I believe when I asked you that question, it was also at the same time I privately asked you to not be so offensive on the list.  That request, apparently, was not heeded.

Again, yet another reason it's probably time to close down the working group.  Or, better yet, get another, tougher skinned, working group chair.


Mark Smith <mark@inet-calendar.net>
Sent by: owner-ietf-calendar@mail.imc.org

11/04/2003 18:35

To
ietf-calendar@imc.org
cc
ned.freed@mrochek.com, hardie@quailcomm.com
Subject
Re: different calendar scales






pregen@egenconsulting.com wrote:
>
> As I have said before, everyone, including you, Mr. Smith, should
> respond to this list with constructive comments only.  I'm really very
> tired of the way this list has turned into a series of nastygrams.  I
> continue to get private notes from people saying they no longer
> particpate on the list because of the tone of many of the notes.
>  Therefore, I want everyone - Doug, Mark, Bruce - everyone - to keep
> notes to calendaring topics.  If it continues, I will go back to the
> IETF management and ask them to remove people from our lists.  That's
> a promise.

Remove me if you want, but Bruce's inaccurate posts and your lack
of willingness to act is killing CAP.  You let him ramble on and
on and on about items that have been in the draft for years without
ever calling consensus. That's not Bruce's or Doug's fault - please act.

You seem to be unwilling or unable to make technical decisions. Just
because Bruce posts does not mean that he is right or accurate. He
almost never posts a proposal and almost never responds to questions
and declares that others misunderstand him. And you seem to be unwilling
or unable to notice.

You asked me in private email if I worked for Doug which I found
insulting.
Do you work for Bruce or are you affiliated with Bruce or his company?
What is you motive for allowing Bruce to post inaccurate information
over and over again and then complain when someone calls Bruce on it?

Looking over the archives I can only find a small handful of times
that you called consensus on anything.  No wonder CAP is not finished.

Doug send me private email about a commercial calendar consortium that
you
and someone else are forming wanting to know if I knew or wanted
to participate (as Doug's company runs our calendar servers). Is that
your motive for not acting on CAP? Did you bother telling this list that
you have commercial motives that may keep you from being impartial?
--=_alternative 00035C3085256DD5_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 20:13:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14585 for ; Tue, 4 Nov 2003 20:13:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50xbkT080495 for ; Tue, 4 Nov 2003 16:59:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA50xbZD080494 for ietf-calendar-bks; Tue, 4 Nov 2003 16:59:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50xZkT080489 for ; Tue, 4 Nov 2003 16:59:36 -0800 (PST) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Calendaring Consortium MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Nov 2003 19:59:45 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/04/2003 07:59:38 PM, Serialize complete at 11/04/2003 07:59:38 PM Content-Type: multipart/alternative; boundary="=_alternative 000578AF85256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000578AF85256DD5_= Content-Type: text/plain; charset="US-ASCII" For anyone interested, this is a link to the preliminary webpage for The Calendaring and Scheduling Consortium. This was to go to the list in a month or so, but Mr. Smith has helped it to make it's appearance a bit earlier. Hopefully, it will clear the air as to the purpose of this effort. Those of you who were in San Francisco will remember the dialogs we started. It's actually going to happen - it's no longer just a dream. http://www.calconnect.org --=_alternative 000578AF85256DD5_= Content-Type: text/html; charset="US-ASCII"
For anyone interested, this is a link to the preliminary webpage for The Calendaring and Scheduling Consortium.  This was to go to the list in a month or so, but Mr. Smith has helped it to make it's appearance a bit earlier.  Hopefully, it will clear the air as to the purpose of this effort.  Those of you who were in San Francisco will remember the dialogs we started.  It's actually going to happen - it's no longer just a dream.

http://www.calconnect.org
--=_alternative 000578AF85256DD5_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 21:16:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16547 for ; Tue, 4 Nov 2003 21:15:59 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5208kT082424 for ; Tue, 4 Nov 2003 18:00:08 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA52086C082423 for ietf-calendar-bks; Tue, 4 Nov 2003 18:00:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5206kT082418 for ; Tue, 4 Nov 2003 18:00:06 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA52036M024730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Nov 2003 18:00:04 -0800 Message-ID: <3FA8599D.7030607@Royer.com> Date: Tue, 04 Nov 2003 18:59:57 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030806060609020706090102" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030806060609020706090102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > I have been, like I am sure everyone else, trying to keep up with the deluge of mail, > particularly from Doug. I think the approach of flooding inbaskets with emails > challenging comments regarding the CAP draft has proven to be a bad one. In the S.F. meeting YOU and Ned endorsed that method and indicated you would stand by me to get CAP out without changes unless they were OVERWHELMINGLY requested by the working group. I posted that once before and you did not challenge or dispute it. If you or the AD's are changing you mind that is fine, but please do not put the load onto me. In fact Ned directed you to not allow changes unless they were OVERWHELMING in a pre-CALSCH meeting that you, Ned, and I participated in at S.F. Then Ned told me in front of you not to change things unless you called consensus (except the items discussed in the calsch meeting). You have not, they have not changed (+/- typo's and such). I can not find the S.F. meeting notes ,but I seem to recall that you made that statement about no changes unless they are OVERWHELMINGLY requested by the WG in the meeting itself. As to me challenging the comments made - I am confused as to who you think would comment on those posts? You have ignored ALL of my private emails to you requesting help on this topic which is why this one is posted publicly. I have declared several times privately and publicly that my issue list went to zero items, and yet you post: > I pulled over 48,000 emails into a tool to try to glean out > where we reached consensus (the few times that we did). I > also did this to come up with an issues list. In the past, > this was either kept by the chair or by the editor. > Since this has not been done by either, I felt I needed > to come up with something. I did and again my list is at ZERO technical items (+/- some typos). Why? - Because YOU and Ned told me NOT to add to change things without you calling a consensus. And you have not, so there is NOTHING for me to do except typo's and such. The latest posts from those wanting changes have little or negligible impact on the protocol and seem more to be disputing if something should have been changed years ago. I can not find a single item that was not discussed on the WG list prior to the changes - can you? And those posts that want new items (GET-CAPABILITY + CALSCALE for example) are NOT on the item list in SF, so per your and Ned's instructions to me - I and not add them. On IMC.ORG there are 12,213 total emails in the archives. (I simply counted the number of lines that started with 'Subject:') so it can't be that far off. I looked in 'current archive' and 'old archive', are there more? Where are the other 35,787 WG emails you talked about above? Perhaps those are the source of confusion? I remember using Bruce's archive in the past and noticed that non-WG calendaring email was in his archive (which is why I stopped using it) - but there were just a few so I do not see that as accounting for the the 35 thousand extra emails. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030806060609020706090102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MDE1OTU3WjAjBgkqhkiG9w0BCQQxFgQUGIL/jeB9y33mSub6wack YMUd5yowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEADmqlPO5XDsD1kXYpv/BLUfR1wMmKfzRtYCZDzpwLziHjl3ZAiKvJ9U+HaXL3cMYV 4CEZfgOB/sTkaWmOa3wWiIcFMs3KMTT6aO/Sbfb3xYmUcgM4zUlRthGWyahAYpOgDfiXB6cj WXEnLCyxmykH+86bQVhmkV4lnsCR5MKIxAdIZZ0IeBlabsEjIxNkolGQNihn4q4XkvT/HMvi IKPPKFiBkP2SDL6RJoNlmama0tfWs5ZYo9Khk+dwk/fzDgSU6GjNRgNHmoegV61szQ5DT7kp TPDVqep8xnPkwKfVhV0RSdtpSl/FQLLG4p16ubbRcMuuSbwljwSklSRNljXU8QAAAAAAAA== --------------ms030806060609020706090102-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 21:51:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17905 for ; Tue, 4 Nov 2003 21:51:21 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52b9kT083321 for ; Tue, 4 Nov 2003 18:37:09 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA52b90S083320 for ietf-calendar-bks; Tue, 4 Nov 2003 18:37:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52b7kT083315 for ; Tue, 4 Nov 2003 18:37:08 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA52b76M025202 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Nov 2003 18:37:08 -0800 Message-ID: <3FA8624D.60209@Royer.com> Date: Tue, 04 Nov 2003 19:37:01 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group References: <000401c3a330$aa445af0$6d9012c0@red.iplanet.com> In-Reply-To: <000401c3a330$aa445af0$6d9012c0@red.iplanet.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080705010709080607060508" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080705010709080607060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > > Would it be possible to get someone like Nathaniel Borenstein to take > the role of a co-editor (if he is interested)? It would help to have a > seasoned veteran of the IETF process to help move things forward. > I would have no problem working with someone. Until my recent post (should precede this one on the list from me). I have not commented on the chairs participation - or lack of. I have been directed by Pat and Ned not to change things, yet Pat does not even comment on posts requesting new action items be opened or on old closed items be reopened. Pat - I have sent you private email in the past and asked that you remind people that I can not change things and that old items are closed for this version of CAP and my emails have not been responded to in any way. Plus you have not returned ANY of my phone calls on creating a new action item list. And the same with Bruce (email only), I have reached out trying to find ways of trying to resolve issues, you (and others) did not respond. at all. Please do not lay the blame on me or this list, if you have action items, post the action item, and Pat you are going to need to reply to those posts and say "no new items" or "yes this one needs to be added". Letting people think that I can unilaterally add/delete/change things is causing some people to get stressed out. There was an action item list. And items were closed and the list went to zero items, and yet some think that if they keep re-posting their objection to debates that they lost, did not participate in (most of the time this one hits the mark), or misunderstood, they they can get their way. No one can respond to all of the requests for history to research each and every item. And even if they did have the time - so what? They seem to NOT be comments on the usability of CAP as written. They seem to be complaints about the process (legitimate but not a CAP stopper). *I* will not open closed items - Pat you can if you want as that is part of your role, but you have to do it, and declare it on the list, or declare items as closed. It will not matter who the editors are, if the chairs can not call consensus when ever there is even one objection, no draft will ever get published. I really am doing my best, but without the chairs calling consensus on *any* CAP items, and without the chairs declaring any CAP debate or CAP action item *ever* as closed in the last year (or more) the only way CAP will ship is when 100% of the list agrees. Simply saying 'I can not find where this was discussed' is not sanctioned reason for me to change/edit/delete an item. And I am not the one that carries the burden do disprove all claims. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080705010709080607060508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MDIzNzAxWjAjBgkqhkiG9w0BCQQxFgQUTFmmUyEE1OO5UpAy+txk eFveztQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAlyWLHFWMTjJTFpxCAULCcuN/he/olCK/qdQ3u/trmebCeqd+CWYLAb2edh19D03J HHvpDj4ybWbNcjYijqXCVurKQfxqmMv2Z8PoisWmFALGZeUQy4TS62xGhMlxbNqZZr80FkL4 O5+NYbjfAwaz08GMHw80rwpxBqSLN1ZlvkbT7IDzaiAOfzoXLMiOXfn9E7qU1Op7Nay9LguU 7DZXCbLDTlgMSCp8FQqPygr1quHVVqPcXBOQF2H/EbB91XGgb6Bwt92Yq9JK9GblA056bZp7 9dZL/FTTvAxPWHKaf+3BwRhjHAsKhgMBMOZtQYT02Geyo4yPnT1gXZTXq0C6vAAAAAAAAA== --------------ms080705010709080607060508-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 21:58:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19069 for ; Tue, 4 Nov 2003 21:58:39 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52kikT083579 for ; Tue, 4 Nov 2003 18:46:44 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA52kiWC083578 for ietf-calendar-bks; Tue, 4 Nov 2003 18:46:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52kgkT083570 for ; Tue, 4 Nov 2003 18:46:43 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA52ke84001068 for ; Tue, 4 Nov 2003 19:46:40 -0700 (MST) Message-ID: <3FA86490.89E8E94C@INET-Calendar.net> Date: Tue, 04 Nov 2003 19:46:40 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Recurrence-ID issue - Comments from the original authors References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thank you Mr Dawson and Stenerson, they are not fixed for life! > In summary, the original intention of the iCalendar specification was > that the value of the RECURRENCE-ID for a specific recurrence instance > would remain unchanged for the duration of the existence of the > recurrence set. Rescheduling individual recurrence instances did not > cause recreation of the recurrence set or change the value of the > RECURRENCE-ID property for the associated recurrence instance, but > only involved changes to the start/end of the recurrence instance. > > Frank Dawson and Derik Stenerson" From owner-ietf-calendar@mail.imc.org Tue Nov 4 22:00:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19257 for ; Tue, 4 Nov 2003 22:00:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52jPkT083531 for ; Tue, 4 Nov 2003 18:45:25 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA52jPlo083530 for ietf-calendar-bks; Tue, 4 Nov 2003 18:45:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.12.113]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52jOkT083522 for ; Tue, 4 Nov 2003 18:45:24 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA52jJ84001023 for ; Tue, 4 Nov 2003 19:45:19 -0700 (MST) Message-ID: <3FA8643F.268014C1@INET-Calendar.net> Date: Tue, 04 Nov 2003 19:45:19 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: different calendar scales References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > Or, better yet, get another, tougher skinned, working group > chair. I would vote for that, I can not find ONE constructive comment or item you have posted in the last year. I can not find that you called conciseness on anything in the last year even when no one objected to a proposal. So, what is your relationship to Bruce/company? I found it odd when researching the archives that you seem to back Bruces inaccurate posts and complain that those who call him on it are less than professional. From owner-ietf-calendar@mail.imc.org Tue Nov 4 22:32:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21260 for ; Tue, 4 Nov 2003 22:32:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA53JekT084832 for ; Tue, 4 Nov 2003 19:19:40 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA53JeIS084831 for ietf-calendar-bks; Tue, 4 Nov 2003 19:19:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA53JdkT084826 for ; Tue, 4 Nov 2003 19:19:39 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA53Jb6M025791 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Nov 2003 19:19:38 -0800 Message-ID: <3FA86C43.3010305@Royer.com> Date: Tue, 04 Nov 2003 20:19:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Calendaring Consortium References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020205000504010700040709" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020205000504010700040709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI - I have contacted via email and phone the contact on that page over a month ago, yet no returned calls or email. I am assuming it is not yet ready for members? And I will talk to Mr. Smiths company about his disclosing what is NDA information between his and my company. Sorry about that I did not mean to let it out, its just they are a partner company and funding some of my projects so I owe them updates as to my plans and intentions. pregen@egenconsulting.com wrote: > > For anyone interested, this is a link to the preliminary webpage for > The Calendaring and Scheduling Consortium. This was to go to the list > in a month or so, but Mr. Smith has helped it to make it's appearance > a bit earlier. Hopefully, it will clear the air as to the purpose of > this effort. Those of you who were in San Francisco will remember the > dialogs we started. It's actually going to happen - it's no longer > just a dream. > > http://www.calconnect.org -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020205000504010700040709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MDMxOTMxWjAjBgkqhkiG9w0BCQQxFgQULJkl39hVlUGvwx773xRt d4ZoydMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA1uhn6Q2IGPpPY0QJoVt6H9r5EOyWyd4Suzt6P+5gBHuvhq0+Bwb0NldCQMGFxb0H LKfSR+39rV/YrJXE+ZCFwXqqT9nHIWomDzAGR4ms8DH+49M9Kp7Awvatppb9XOX8syh9x62C VQ55j92nCbDIfz4JwPS1L0okNYsrldYhIW2PScyjAGGfS7DZWCFcarWP0Ilig8kvadPkOwYU 2edKrtd2wNGw+eoVKxTzmfGl8xXg+ZN+ovjFIyBAL7FMEQsx7ID2tu5XwcVamOfPJExBKXUT wpHIXByClcXM67UFVA865XcLdkKIIhuC60wSb7qpi+4z2ksWSd2GN5aDedJFjgAAAAAAAA== --------------ms020205000504010700040709-- From owner-ietf-calendar@mail.imc.org Tue Nov 4 23:31:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22879 for ; Tue, 4 Nov 2003 23:31:59 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA54FekT087155 for ; Tue, 4 Nov 2003 20:15:40 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA54FeeB087154 for ietf-calendar-bks; Tue, 4 Nov 2003 20:15:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA54FckT087147 for ; Tue, 4 Nov 2003 20:15:38 -0800 (PST) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Fw: different calendar scales MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Nov 2003 23:15:49 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/04/2003 11:15:41 PM, Serialize complete at 11/04/2003 11:15:41 PM Content-Type: multipart/alternative; boundary="=_alternative 00176BFE85256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00176BFE85256DD5_= Content-Type: text/plain; charset="US-ASCII" First, my apologies to the list for forgetting to cc: all recipients on the original note. And second, my apologies to the list for this flurry of less-than-productive emails. Hopefully, they will stop soon.... ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ----- Forwarded by Pat R Egen/Egen Consulting/01 on 11/04/2003 23:14 ----- Pat R Egen/Egen Consulting/01 11/04/2003 23:14 To Mark Smith cc Subject Re: different calendar scales You have your opinion. That's what makes this a great world. We all can have opinions. As to my relationship with Bruce. He is my friend. I have no other relationship other than that and the fact I have always found him to be a kind person with a lot of enthusiam. Sometimes, his enthusiam is intense. But, then, isn't that true of all of us who are passionate about what we feel is important. Whenever Bruce has been able to attend our IETF meetings, he brings us back into focus. He hounds at the topic until both he and the rest of us "get it." Bob and I miss it when he's not able to participate at the meetings or on the list. That's why we lobbyed for him to be the Method Reviewer of RFC2445 2446 and 2447. We know he would keep us honest. As for the last year, and no valid comments. Yes, indeed, that is very true. Especially since it has been nearly impossible to figure out what is concensus and what is not. It really started in March after the San Francisco meeting. Nothing like making a last call to bring out the best of us...... ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 11/04/2003 21:45 To ietf-calendar@imc.org cc Subject Re: different calendar scales pregen@egenconsulting.com wrote: > Or, better yet, get another, tougher skinned, working group > chair. I would vote for that, I can not find ONE constructive comment or item you have posted in the last year. I can not find that you called conciseness on anything in the last year even when no one objected to a proposal. So, what is your relationship to Bruce/company? I found it odd when researching the archives that you seem to back Bruces inaccurate posts and complain that those who call him on it are less than professional. --=_alternative 00176BFE85256DD5_= Content-Type: text/html; charset="US-ASCII"
First, my apologies to the list for forgetting to cc: all recipients on the original note.  And second, my apologies to the list for this flurry of less-than-productive emails.  Hopefully, they will stop soon....
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
----- Forwarded by Pat R Egen/Egen Consulting/01 on 11/04/2003 23:14 -----
Pat R Egen/Egen Consulting/01

11/04/2003 23:14

To
Mark Smith <mark@inet-calendar.net>
cc
Subject
Re: different calendar scalesLink






You have your opinion.  That's what makes this a great world.  We all can have opinions.  As to my relationship with Bruce.  He is my friend.  I have no other relationship other than that and the fact I have always found him to be a kind person with a lot of enthusiam.  Sometimes, his enthusiam is intense.  But, then, isn't that true of all of us who are passionate about what we feel is important.  Whenever Bruce has been able to attend our IETF meetings, he brings us back into focus.  He hounds at the topic until both he and the rest of us "get it."  Bob and I miss it when he's not able to participate at the meetings or on the list.  That's why we lobbyed for him to be the Method Reviewer of RFC2445 2446 and 2447.  We know he would keep us honest.

As for the last year, and no valid comments.  Yes, indeed, that is very true.  Especially since it has been nearly impossible to figure out what is concensus and what is not.  It really started in March after the San Francisco meeting.  Nothing like making a last call to bring out the best of us......  
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Mark Smith <mark@inet-calendar.net>
Sent by: owner-ietf-calendar@mail.imc.org

11/04/2003 21:45


To
ietf-calendar@imc.org
cc
Subject
Re: different calendar scales








pregen@egenconsulting.com wrote:

> Or, better yet, get another, tougher skinned, working group
> chair.

I would vote for that, I can not find ONE constructive comment
or item you have posted in the last year. I can not find that
you called conciseness on anything in the last year even when
no one objected to a proposal.

So, what is your relationship to Bruce/company?
I found it odd when researching the archives that you seem to back
Bruces inaccurate posts and complain that those who call him on
it are less than professional.
 --=_alternative 00176BFE85256DD5_=-- From bmicro@email.com Wed Nov 5 07:16:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02500 for ; Wed, 5 Nov 2003 07:16:16 -0500 (EST) Received: from SU-U9KAW0C0W59H ([220.173.226.99]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA5C0YkT075230 for ; Wed, 5 Nov 2003 04:00:36 -0800 (PST) (envelope-from bmicro@email.com) Message-Id: <200311051200.hA5C0YkT075230@above.proper.com> From: "belaine@yahoo.com" To: "ietf-calendar-bks@above.proper.com" Subject: join the many Americans enlarging their penises! 4u3243280432 Date: Wed, 5 Nov 2003 19:59:19 +0800 X-Priority: 3 (normal) Importance: Normal X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQoNCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+bmE8L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgdG9wbWFyZ2luPSIwIiBiZ2NvbG9yPSIjMzMwMDY2Ij4NCjxkaXYgYWxpZ249ImNlbnRlciI+ PGJyPjwzMTI4Nnkycz4NCjx0YWJsZSB3aWR0aD01MDBweD4NCjx0cj4NCjx0ZCBiZ2NvbG9yPSJu YXZ5IiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJ2ZXJkYW5hIiBzaXplPTIgY29sb3I9Inll bGxvdyI+MTAwJSBHdWFyYW50ZWVkIFJlc3VsdHMgT3IgWW91ciBNb25leSBCYWNrDQo8L3RyPg0K PHRyPjx0ZCBiZ2NvbG9yPSJibHVlIiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJ2ZXJkYW5h IiBzaXplPTQgY29sb3I9IndoaXRlIj48Yj4NCjxicj4NCkxpa2UgZ2lybHMgd2l0aCBiaWcgdGl0 cz8gR2lybHMgbGlrZSBiaWcgY29ja3Mgb24gZ3V5cyE8YnI+PGJyPg0KPCEtLSAzMTI4NnkycyAt LT4NCkhvdyB3b3VsZCB5b3UgZmVlbCBoYXZpbmcgYSBmZXcgZXh0cmEgaW5jaGVzLCBhbmQgYSBi aWcgYW5kIGNvbW1hbmRpbmcgcGVuaXM/PGJyPjxicj4NClRoZSBEaWZmZXJlbmNlIGlzIHdvcnRo IHdyaXRpbmcgaG9tZSBhYm91dCEgT3VyIHBlbmlzIHBpbGxzIGhhdmUgYSBzdHJvbmcgcmVwdXRh dGlvbiE8YnI+PGJyPg0KPEEgaHJlZj0iaHR0cDovL3NoZWZmaWVsZEB3d3cuaGVyYmFsdXNhLmJp ei93aGl0ZWxpbmUvdnAvPzMxMjg2eTJzIj48Zm9udCBjb2xvcj0ieWVsbG93Ij5UYWtlIGEgbG9v ayBhdCBob3cgaXQgd29ya3M8L2E+PGJyPjxicj4NCjwvdGQ+PC90cj4NCjx0cj4NCjx0ZCBiZ2Nv bG9yPSJuYXZ5IiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJ2ZXJkYW5hIiBzaXplPTIgY29s b3I9InllbGxvdyI+V29ybGRzIE1vc3QgRWZmZWN0aXZlIEVubGFyZ2VtZW50IFRlY2huaXF1ZQ0K PC90cj4NCjwvdGFibGU+PDNiZnl1c3NrYWhiPg0KPGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJy Pjxicj4NCjxmb250IHNpemU9IjFweCIgZmFjZT0idmVyZGFuYSIgY29sb3I9IiMwMDAwMCI+M2Jm eXVzc2thaGIgMzEyODZ5MnMgM2JmeXVzc2thaGI8L2ZvbnQ+DQo8M2JmeXVzc2thaGI+DQo8YSBo cmVmPSJodHRwOi8vc2hlZmZpZWxkQHd3dy5oZXJiYWx1c2EuYml6L3doaXRlbGluZS9vdXQuaHRt bCI+PGZvbnQgY29sb3I9InllbGxvdyIgc2l6ZT0iMiI+dG8gZ2V0IG9mZjwvYT4NCjwvYm9keT4N CjwvaHRtbD4NCg== From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:05:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08174 for ; Wed, 5 Nov 2003 10:05:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Em9kT082848 for ; Wed, 5 Nov 2003 06:48:09 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Em9dg082847 for ietf-calendar-bks; Wed, 5 Nov 2003 06:48:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Em8kT082842 for ; Wed, 5 Nov 2003 06:48:08 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA7F459.48FFEEF3@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: CAP-12-e: CAP-VERSION Property MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Nov 2003 09:40:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 09:48:08 AM, Serialize complete at 11/05/2003 09:48:08 AM Content-Type: multipart/alternative; boundary="=_alternative 00503C0885256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00503C0885256DD5_= Content-Type: text/plain; charset="US-ASCII" Mark quiped on 11/04/2003 01:47:53 PM: > > Did we actually discuss exchanging "1.0" for the RFC number at some > > point? > > Look closer. As usual - you miss what you disagree with. I already said I did a full text search on "CAP-VERSION" which should be in any posting where it was to be discussed and found no WG postings between April where it was "1.0" and June where Doug posted it as the RFC number. If you wont provide at least a thread reference then please dont waste our cycles. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 00503C0885256DD5_= Content-Type: text/html; charset="US-ASCII"
Mark quiped on 11/04/2003 01:47:53 PM:
> > Did we actually discuss exchanging "1.0" for the RFC number at some
> > point?  
>
> Look closer. As usual - you miss what you disagree with.
I already said I did a full text search on "CAP-VERSION" which should be in any posting where it was to be discussed and found no WG postings between April where it was "1.0" and June where Doug posted it as the RFC number.  If you wont provide at least a thread reference then please dont waste our cycles.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 00503C0885256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:07:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08372 for ; Wed, 5 Nov 2003 10:07:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5ElpkT082815 for ; Wed, 5 Nov 2003 06:47:51 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5ElpXt082814 for ietf-calendar-bks; Wed, 5 Nov 2003 06:47:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.pspl.co.in (www.pspl.co.in [202.54.11.65] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5ElmkT082805 for ; Wed, 5 Nov 2003 06:47:49 -0800 (PST) (envelope-from payod_deshpande@persistent.co.in) Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id hA5EltPY017126 for ; Wed, 5 Nov 2003 20:17:55 +0530 Received: from ps1056 (PS1056.intranet.pspl.co.in [192.168.1.88]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id hA5Elsob017113 for ; Wed, 5 Nov 2003 20:17:55 +0530 Message-ID: <00ee01c3a3ab$c4b95040$5801a8c0@persistent.co.in> From: "Payod Deshpande" To: Subject: Degree of conformance with iCal, iTIP, iMIP Date: Wed, 5 Nov 2003 20:17:42 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=7.0 tests=none version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello everyone, I need to add a calendaring support to a mail client. I want to know to what extent Outlook, Notes and Groupwise comply with these standards? In other words to what extent do I need to comply with these standards to be interoperable with these clients. Regards, Payod Deshpande Persistent Systems Pvt. Ltd. From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:23:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09826 for ; Wed, 5 Nov 2003 10:23:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FACkT083820 for ; Wed, 5 Nov 2003 07:10:12 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FACF2083819 for ietf-calendar-bks; Wed, 5 Nov 2003 07:10:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FABkT083814 for ; Wed, 5 Nov 2003 07:10:12 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-e: 8.22 MULTIPART Property ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Nov 2003 10:06:34 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 10:10:11 AM, Serialize complete at 11/05/2003 10:10:11 AM Content-Type: multipart/alternative; boundary="=_alternative 0052A7C985256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0052A7C985256DD5_= Content-Type: text/plain; charset="US-ASCII" In looking at the CAP-12-e draft I see in Section 8.22 MULTIPART Property the following: 8.22 MULTIPART Property Property Name: MULTIPART [Snip, snip] Formal Definition: The property is defined by the following notation: name = "MULTIPART" other-params ":" text *( "," text) CRLF so this section is defining an ABNF for 'name' to be used elsewhere. But the next section 8.23 NAME Property says: 8.23 NAME Property Property Name: NAME [Snip, snip] Formal Definition: The property is defined by the following notation: name = "NAME" nameparam ":" text CRLF which appears to define the same ABNF value. This is not goodness (or at least it should be using the "/=" instead of "=" if it were an extension of name) I suspect that the ABNF under Section 8.22 just needs touching up and any references to MULTIPART need to be santiy checked. 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 0052A7C985256DD5_= Content-Type: text/html; charset="US-ASCII"
In looking at the CAP-12-e draft I see in Section 8.22 MULTIPART Property the following:

8.22 MULTIPART Property

  Property Name: MULTIPART
[Snip, snip]
   Formal Definition: The property is defined by the following notation:


  name = "MULTIPART" other-params ":" text *( "," text) CRLF

so this section is defining an ABNF for 'name' to be used elsewhere.  But the next section 8.23 NAME Property says:

8.23 NAME Property

  Property Name: NAME
[Snip, snip]
   Formal Definition: The property is defined by the following notation:

  name = "NAME" nameparam ":" text CRLF

which appears to define the same ABNF value.  This is not goodness (or at least it should be using the "/=" instead of "=" if it were an extension of name)

I suspect that the ABNF under Section 8.22 just needs touching up and any references to MULTIPART need to be santiy checked.

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 0052A7C985256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:28:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09997 for ; Wed, 5 Nov 2003 10:28:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FH6kT084104 for ; Wed, 5 Nov 2003 07:17:06 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FH6Ft084100 for ietf-calendar-bks; Wed, 5 Nov 2003 07:17:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FH5kT084091 for ; Wed, 5 Nov 2003 07:17:06 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-e: 'text' not in ABNF MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Nov 2003 10:10:52 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 10:17:04 AM, Serialize complete at 11/05/2003 10:17:04 AM Content-Type: multipart/alternative; boundary="=_alternative 00530C6885256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00530C6885256DD5_= Content-Type: text/plain; charset="US-ASCII" In trying to answer a question for someone I tried to show them where in CAP-12-e we had ABNF for 'text' but I can find none nor any reference to whose 'text' definition is being used. This should be included in CAP-12-e for completeness in accurately building a CAP parser. 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 00530C6885256DD5_= Content-Type: text/html; charset="US-ASCII"
In trying to answer a question for someone I tried to show them where in CAP-12-e we had ABNF for 'text' but I can find none nor any reference to whose 'text' definition is being used.  This should be included in CAP-12-e for completeness in accurately building a CAP parser.

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 00530C6885256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:28:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10013 for ; Wed, 5 Nov 2003 10:28:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FH6kT084107 for ; Wed, 5 Nov 2003 07:17:06 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FH6HJ084106 for ietf-calendar-bks; Wed, 5 Nov 2003 07:17:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FH5kT084092 for ; Wed, 5 Nov 2003 07:17:06 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA7FAF1.2050508@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-e: CAP-VERSION Property MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Nov 2003 10:11:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 10:17:04 AM, Serialize complete at 11/05/2003 10:17:04 AM Content-Type: multipart/alternative; boundary="=_alternative 0053263D85256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053263D85256DD5_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/04/2003 02:16:01 PM: > > My appologies for not be more precise in the question. I was > > referring to using a numeric values like VERSION (which actually is > > biparted): > > Do you have a proposal? It does not look like it to me. I clearly indicated that it was a question, not something that required a proposal to resolve. By your constant avoidance to the question Ill have to assume that you made the change arbitrarily without WG discussion or concensus by virtue of being the sole current editor. If Im wrong then fine but I can find no WG discussion on the changes that Im asking about or the questionable ABNF I find. As recent as April 2003 it was described one way and all of a sudden in June 2003 it was different. Since you have said (in part but not out of context): It is a multivalued field... I think its fair to question the non-multivalued ABNF that is currently there. In case you were not aware, the current ABNF does NOT indicate that CAP-VERSION is multivalued. It is just: cap-version = "CAP-VERSION" other-params ":" text CRLF which means CAP-VERSION is single valued; a single 'text' value. If you want to see an example of a multivalued ABNF then check out my provided ABNF or the one in Section 8.22 MULTIPART Property name = "MULTIPART" other-params ":" text *( "," text) 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 0053263D85256DD5_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/04/2003 02:16:01 PM:
> > My appologies for not be more precise in the question.  I was
> > referring to using a numeric values like VERSION (which actually is
> > biparted):
>
> Do you have a proposal? It does not look like it to me.
I clearly indicated that it was a question, not something that required a proposal to resolve.  

By your constant avoidance to the question Ill have to assume that you made the change arbitrarily without WG discussion or concensus by virtue of being the sole current editor.  If Im wrong then fine but I can find no WG discussion on the changes that Im asking about or the questionable ABNF I find.  As recent as April 2003 it was described one way and all of a sudden in June 2003 it was different.

Since you have said (in part but not out of context):

It is a multivalued field...

I think its fair to question the non-multivalued ABNF that is currently there.  In case you were not aware, the current ABNF does NOT indicate that CAP-VERSION is multivalued.  It is just:

   cap-version   = "CAP-VERSION" other-params ":" text CRLF

which means CAP-VERSION is single valued; a single 'text' value.  If you want to see an example of a multivalued ABNF then check out my provided ABNF or the one in Section 8.22 MULTIPART Property

   name = "MULTIPART" other-params ":" text *( "," text) 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 0053263D85256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:49:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10850 for ; Wed, 5 Nov 2003 10:49:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FYWkT085010 for ; Wed, 5 Nov 2003 07:34:32 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FYWHi085009 for ietf-calendar-bks; Wed, 5 Nov 2003 07:34:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.web.de (smtp01.web.de [217.72.192.180]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FYVkT084944 for ; Wed, 5 Nov 2003 07:34:31 -0800 (PST) (envelope-from matthias.laabs@web.de) Received: from [147.32.97.44] (helo=jasminelee.mk.cvut.cz) by smtp.web.de with asmtp (WEB.DE 4.99 #516) id 1AHPfq-0005Om-00 for ietf-calendar@imc.org; Wed, 05 Nov 2003 16:34:22 +0100 From: Matthias Laabs To: ietf-calendar@imc.org Subject: How to define a CALSCALE? Date: Wed, 5 Nov 2003 16:33:27 +0100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311051633.27562.matthias.laabs@web.de> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I am interested in writing a CALSCALE for JALALI(persian) calendar. Where can I find information on how to write or where to propose it. Is the Gregorian CALSCALE defined somewhere? Thanks in advance, Matthias From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:59:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11128 for ; Wed, 5 Nov 2003 10:59:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FlJkT085468 for ; Wed, 5 Nov 2003 07:47:19 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FlJ2Y085466 for ietf-calendar-bks; Wed, 5 Nov 2003 07:47:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FlIkU085455 for ; Wed, 5 Nov 2003 07:47:19 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA8624D.60209@Royer.com> To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Nov 2003 10:31:49 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 10:47:16 AM, Serialize complete at 11/05/2003 10:47:16 AM Content-Type: multipart/alternative; boundary="=_alternative 0054F7C185256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054F7C185256DD5_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 11/04/2003 09:37:01 PM: > And the same with > Bruce (email only), I have reached out trying to find ways of trying > to resolve issues, you (and others) did not respond. at all. This is patently false with respect to me. I have responded privately to each and every email you have sent privately since Ive been on the WG with you (with the exception of some jokes you've sent). There has not been a single message I did not receive that I did not respond to. This is equally true for any private mail from other WG members. While we may not see eye to eye at times, I do not slight anyone by ignoring them. I at least have the courtesy to send back a response of some kind because I would expect the same treatement. 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 0054F7C185256DD5_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 11/04/2003 09:37:01 PM:
>                                                         And the same with
> Bruce  (email only), I have reached out trying to find ways of trying
> to resolve issues, you (and others) did not respond. at all.

This is patently false with respect to me.

I have responded privately to each and every email you have sent privately since Ive been on the WG with you (with the exception of some jokes you've sent).  There has not been a single message I did not receive that I did not respond to.  This is equally true for any private mail from other WG members.

While we may not see eye to eye at times, I do not slight anyone by ignoring them.  I at least have the courtesy to send back a response of some kind because I would expect the same treatement.

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 0054F7C185256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 10:59:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11145 for ; Wed, 5 Nov 2003 10:59:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FlJkT085462 for ; Wed, 5 Nov 2003 07:47:19 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FlJ5v085460 for ietf-calendar-bks; Wed, 5 Nov 2003 07:47:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FlIkT085455 for ; Wed, 5 Nov 2003 07:47:18 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FA81601.3050205@Royer.com> To: ietf-calendar@imc.org Subject: Re: EXPAND property: All instances? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Nov 2003 10:18:51 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 10:47:16 AM, Serialize complete at 11/05/2003 10:47:16 AM Content-Type: multipart/alternative; boundary="=_alternative 0053C78285256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053C78285256DD5_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 11/04/2003 04:11:29 PM: > > I have a simple question regarding the EXPAND property. In CAP-12-e > > it is described as: > > > > Description: If a CUA wishes to see all of the instances of a > > recurring component the CUA sets EXPAND=TRUE in the "VQUERY" > > component. If not specified, the default is FALSE. Note that if the > > CS has its "RECUR-EXPAND" CS property value set to false then the > > "EXPAND" property will be ignored and the result will be as if the > > "EXPAND" value was set to false. > > > > My question is simply this: Is the CS supposed to return literally > > all instances of a repeating entry even if they fall outside the > > bounds of the parameters in the VQUERY? > > I assume you mean - you want the text fixed? Or are you really confused? Its a straight forward question: Is the intent of EXPAND to literally return all instances of any repeating entry even if its outside the bounds of the WHERE clause or is the Description text incorrect? Im trying to understand its purpose and how it affects the other parts of CAP like SEARCHing. Either its poorly described or the intent is somewhat questionable, at least to me (see the rest of my original posting for more info). 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 0053C78285256DD5_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 11/04/2003 04:11:29 PM:
> > I have a simple question regarding the EXPAND property.  In CAP-12-e
> > it is described as:
> >
> >    Description: If a CUA wishes to see all of the instances of a
> >   recurring component the CUA sets EXPAND=TRUE in the "VQUERY"
> >   component. If not specified, the default is FALSE. Note that if the
> >   CS has its "RECUR-EXPAND" CS property value set to false then the
> >   "EXPAND" property will be ignored and the result will be as if the
> >   "EXPAND" value was set to false.
> >
> > My question is simply this:  Is the CS supposed to return literally
> > all instances of a repeating entry even if they fall outside the
> > bounds of the parameters in the VQUERY?
>
> I assume you mean - you want the text fixed? Or are you really confused?
Its a straight forward question: Is the intent of EXPAND to literally return all instances of any repeating entry even if its outside the bounds of the WHERE clause or is the Description text incorrect?

Im trying to understand its purpose and how it affects the other parts of CAP like SEARCHing.  Either its poorly described or the intent is somewhat questionable, at least to me (see the rest of my original posting for more info).

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 0053C78285256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 11:11:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11476 for ; Wed, 5 Nov 2003 11:11:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FvOkT085836 for ; Wed, 5 Nov 2003 07:57:24 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5FvOUT085835 for ietf-calendar-bks; Wed, 5 Nov 2003 07:57:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5FvMkT085821 for ; Wed, 5 Nov 2003 07:57:22 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <00ee01c3a3ab$c4b95040$5801a8c0@persistent.co.in> To: "Payod Deshpande" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Degree of conformance with iCal, iTIP, iMIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 5 Nov 2003 10:57:32 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/05/2003 10:57:24 AM, Serialize complete at 11/05/2003 10:57:24 AM Content-Type: multipart/alternative; boundary="=_alternative 0057AA7A85256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057AA7A85256DD5_= Content-Type: text/plain; charset="US-ASCII" Hi Payod. There is no formal document that states which vendor supports which standard or how much of each standard they support. What others have done is contacted each vendor individually. In order to interoperate with the vendors (any vendors) you need to handle all the MUST and SHOULDS of RFC 2445, 2446, 2447. That's what we use to test interoperability. In addition, when you have a product that is ready, you should attend an interoperability testing event. We've had three so far, and are long overdue for another one. The economy has forced several of the past participants to put testing on hold. I also suggest you read the Guide to Internet Calendaring (RFC 3283). You can find past interop results at http://www.calsch.org. You will see what vendors participated, but you will not see how each vendor fared. It is the policy of the IETF that interop results are "anonymous" to the public. "Payod Deshpande" Sent by: owner-ietf-calendar@mail.imc.org 11/05/2003 09:47 To cc Subject Degree of conformance with iCal, iTIP, iMIP Hello everyone, I need to add a calendaring support to a mail client. I want to know to what extent Outlook, Notes and Groupwise comply with these standards? In other words to what extent do I need to comply with these standards to be interoperable with these clients. Regards, Payod Deshpande Persistent Systems Pvt. Ltd. --=_alternative 0057AA7A85256DD5_= Content-Type: text/html; charset="US-ASCII"
Hi Payod.  There is no formal document that states which vendor supports which standard or how much of each standard they support.  What others have done is contacted each vendor individually.  

In order to interoperate with the vendors (any vendors) you need to handle all the MUST and SHOULDS of RFC 2445, 2446, 2447.  That's what we use to test interoperability.  

In addition, when you have a product that is ready, you should attend an interoperability testing event.  We've had three so far, and are long overdue for another one.  The economy has forced several of the past participants to put testing on hold.  

I also suggest you read the Guide to Internet Calendaring (RFC 3283).  You can find past interop results at http://www.calsch.org.  You will see what vendors participated, but you will not see how each vendor fared.  It is the policy of the IETF that interop results are "anonymous" to the public.


"Payod Deshpande" <payod_deshpande@persistent.co.in>
Sent by: owner-ietf-calendar@mail.imc.org

11/05/2003 09:47

To
<ietf-calendar@imc.org>
cc
Subject
Degree of conformance with iCal, iTIP, iMIP






Hello everyone,

I need to add a calendaring support to a mail client. I want to know to what
extent Outlook, Notes and Groupwise comply with these standards? In other
words to what extent do I need to comply with these standards to be
interoperable with these clients.

Regards,
Payod Deshpande

Persistent Systems Pvt. Ltd.
--=_alternative 0057AA7A85256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 11:38:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12304 for ; Wed, 5 Nov 2003 11:38:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GLdkT086903 for ; Wed, 5 Nov 2003 08:21:39 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5GLdOQ086902 for ietf-calendar-bks; Wed, 5 Nov 2003 08:21:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GLbkT086889 for ; Wed, 5 Nov 2003 08:21:37 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FA86C43.3010305@Royer.com> To: ietf-calendar@imc.org Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: Calendaring Consortium MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 5 Nov 2003 11:21:49 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/05/2003 11:21:38 AM, Serialize complete at 11/05/2003 11:21:38 AM Content-Type: multipart/alternative; boundary="=_alternative 0059E3C385256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059E3C385256DD5_= Content-Type: text/plain; charset="US-ASCII" Thanks for the update, Doug. A month ago, we were still in discussions about where the consortium was going and how it would be structured. the calconnect.org domain name was just ordered. I know that the executive director sent at least one note to all people who had expressed interest after San Francisco. I wanted it to be firmer before we put any more details on the list. However, Mr. Smith has actually helped the effort by spilling the beans. It was not a secret - we just wanted it to look more like we knew what we doing. 8-) ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 11/04/2003 22:19 Please respond to ietf-calendar@imc.org To "ietf-calendar@imc.org" cc Subject Re: Calendaring Consortium FYI - I have contacted via email and phone the contact on that page over a month ago, yet no returned calls or email. I am assuming it is not yet ready for members? And I will talk to Mr. Smiths company about his disclosing what is NDA information between his and my company. Sorry about that I did not mean to let it out, its just they are a partner company and funding some of my projects so I owe them updates as to my plans and intentions. pregen@egenconsulting.com wrote: > > For anyone interested, this is a link to the preliminary webpage for > The Calendaring and Scheduling Consortium. This was to go to the list > in a month or so, but Mr. Smith has helped it to make it's appearance > a bit earlier. Hopefully, it will clear the air as to the purpose of > this effort. Those of you who were in San Francisco will remember the > dialogs we started. It's actually going to happen - it's no longer > just a dream. > > http://www.calconnect.org -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 0059E3C385256DD5_= Content-Type: text/html; charset="US-ASCII"
Thanks for the update, Doug.  A month ago, we were still in discussions about where the consortium was going and how it would be structured.  the calconnect.org domain name was just ordered.  I know that the executive director sent at least one note to all people who had expressed interest after San Francisco.  I wanted it to be firmer before we put any more details on the list.  However, Mr. Smith has actually helped the effort by spilling the beans.  It was not a secret - we just wanted it to look more like we knew what we doing.  8-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

11/04/2003 22:19
Please respond to
ietf-calendar@imc.org
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: Calendaring Consortium






FYI - I have contacted via email and phone the contact on that page over
a month ago, yet no returned calls or email. I am assuming it is not yet
ready
for members?

And I will talk to Mr. Smiths company about his disclosing what is NDA
information
between his and my company. Sorry about that I did not mean to let it
out, its just
they are a partner company and funding some of my projects so I owe them
updates
as to my plans and intentions.

pregen@egenconsulting.com wrote:

>
> For anyone interested, this is a link to the preliminary webpage for
> The Calendaring and Scheduling Consortium.  This was to go to the list
> in a month or so, but Mr. Smith has helped it to make it's appearance
> a bit earlier.  Hopefully, it will clear the air as to the purpose of
> this effort.  Those of you who were in San Francisco will remember the
> dialogs we started.  It's actually going to happen - it's no longer
> just a dream.
>
> http://www.calconnect.org


--

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

              We Do Standards - You Need Standards
--=_alternative 0059E3C385256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 12:08:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13188 for ; Wed, 5 Nov 2003 12:08:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GsJkT088890 for ; Wed, 5 Nov 2003 08:54:19 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5GsJ1b088889 for ietf-calendar-bks; Wed, 5 Nov 2003 08:54:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GsHkT088882 for ; Wed, 5 Nov 2003 08:54:18 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FA8599D.7030607@Royer.com> To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 5 Nov 2003 11:54:27 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/05/2003 11:54:19 AM, Serialize complete at 11/05/2003 11:54:19 AM Content-Type: multipart/alternative; boundary="=_alternative 005CE06785256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CE06785256DD5_= Content-Type: text/plain; charset="US-ASCII" I appreciate your comments Doug. However, Ned nor I ever stated it was ok to flood inbaskets with email in order to stop people from raising objections to items on the draft. I admit fully that I should have stepped in much earlier and put a stop to it. I know I did send out an email a while ago stating that we needed to keep the emails short and germaine to the issues. Go to http://www.ietf.org/proceedings/03mar/index.html for a copy of the minutes from that meeting. You will note that one of the things we talked about was closing the working group. It's been kept open to try to update RFC 2445, 2446 and 2447. I've failed at getting an editor to work on these items. In addition, I failed to do a good job at keeping the emails to a reasonable number. I realize this now after trying to get through 48,000 to look for concensus. I have sent out emails pleading for a reduction in the amount of emails and the deluge. I will formulate a note showing dates and times. However, you bring up a valid point. I did fail to stop the traffic. Yet another good reason to get another chair. Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 11/04/2003 20:59 Please respond to ietf-calendar@imc.org To ietf-calendar@imc.org cc Subject Re: Status of the CALSCH working group > > I have been, like I am sure everyone else, trying to keep up with the deluge of mail, > particularly from Doug. I think the approach of flooding inbaskets with emails > challenging comments regarding the CAP draft has proven to be a bad one. In the S.F. meeting YOU and Ned endorsed that method and indicated you would stand by me to get CAP out without changes unless they were OVERWHELMINGLY requested by the working group. I posted that once before and you did not challenge or dispute it. If you or the AD's are changing you mind that is fine, but please do not put the load onto me. In fact Ned directed you to not allow changes unless they were OVERWHELMING in a pre-CALSCH meeting that you, Ned, and I participated in at S.F. Then Ned told me in front of you not to change things unless you called consensus (except the items discussed in the calsch meeting). You have not, they have not changed (+/- typo's and such). I can not find the S.F. meeting notes ,but I seem to recall that you made that statement about no changes unless they are OVERWHELMINGLY requested by the WG in the meeting itself. As to me challenging the comments made - I am confused as to who you think would comment on those posts? You have ignored ALL of my private emails to you requesting help on this topic which is why this one is posted publicly. I have declared several times privately and publicly that my issue list went to zero items, and yet you post: > I pulled over 48,000 emails into a tool to try to glean out > where we reached consensus (the few times that we did). I > also did this to come up with an issues list. In the past, > this was either kept by the chair or by the editor. > Since this has not been done by either, I felt I needed > to come up with something. I did and again my list is at ZERO technical items (+/- some typos). Why? - Because YOU and Ned told me NOT to add to change things without you calling a consensus. And you have not, so there is NOTHING for me to do except typo's and such. The latest posts from those wanting changes have little or negligible impact on the protocol and seem more to be disputing if something should have been changed years ago. I can not find a single item that was not discussed on the WG list prior to the changes - can you? And those posts that want new items (GET-CAPABILITY + CALSCALE for example) are NOT on the item list in SF, so per your and Ned's instructions to me - I and not add them. On IMC.ORG there are 12,213 total emails in the archives. (I simply counted the number of lines that started with 'Subject:') so it can't be that far off. I looked in 'current archive' and 'old archive', are there more? Where are the other 35,787 WG emails you talked about above? Perhaps those are the source of confusion? I remember using Bruce's archive in the past and noticed that non-WG calendaring email was in his archive (which is why I stopped using it) - but there were just a few so I do not see that as accounting for the the 35 thousand extra emails. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 005CE06785256DD5_= Content-Type: text/html; charset="US-ASCII"
I appreciate your comments Doug.  However, Ned nor I ever stated it was ok to flood inbaskets with email in order to stop people from raising objections to items on the draft.  I admit fully that I should have stepped in much earlier and put a stop to it.  I know I did send out an email a while ago stating that we needed to keep the emails short and germaine to the issues.   Go to http://www.ietf.org/proceedings/03mar/index.html for a copy of the minutes from that meeting.  You will note that one of the things we talked about was closing the working group.  It's been kept open to try to update RFC 2445, 2446 and 2447.  I've failed at getting an editor to work on these items.

In addition, I failed to do a good job at keeping the emails to a reasonable number.  I realize this now after trying to get through 48,000 to look for concensus.  I have sent out emails pleading for a reduction in the amount of emails and the deluge.  I will formulate a note showing dates and times.  However, you bring up a valid point.  I did fail to stop the traffic.  Yet another good reason to get another chair.


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

11/04/2003 20:59
Please respond to
ietf-calendar@imc.org
To
ietf-calendar@imc.org
cc
Subject
Re: Status of the CALSCH working group





 
>
> I have been, like I am sure everyone else, trying to keep up with the
deluge of mail,
> particularly from Doug.  I think the approach of flooding inbaskets
with emails
> challenging comments regarding the CAP draft has proven to be a bad
one.

In the S.F. meeting YOU and Ned endorsed that method and indicated you
would stand by
me to get CAP out without changes unless they were OVERWHELMINGLY requested
by the working group. I posted that once before and you did not
challenge or dispute it. If you
or the AD's are changing you mind that is fine, but please do not put
the load onto me.

In fact Ned directed you to not allow changes unless they were OVERWHELMING
in a pre-CALSCH meeting that you, Ned, and I participated in at S.F.
Then Ned told me
in front of you not to change things unless you called consensus (except
the items discussed
in the calsch meeting). You have not, they have not changed (+/- typo's
and such).
I can not find the S.F. meeting notes ,but I seem to recall that you
made that statement
about no changes unless they are OVERWHELMINGLY requested by the WG
in the meeting itself.

As to me challenging the comments made - I am confused as to who you
think would comment on those posts?

You have ignored ALL of my private emails to you requesting help on this
topic which is why this one is posted publicly.

I have declared several times privately and publicly that my issue list
went to zero items,
and yet you post:

> I pulled over 48,000 emails into a tool to try to glean out
> where we reached consensus (the few times that we did). I
> also did this to come up with an issues list.  In the past,
> this was either kept by the chair or by the editor.
> Since this has not been done by either, I felt I needed
> to come up with something.

I did and again my list is at ZERO technical items (+/- some typos).
Why? - Because YOU and Ned told me NOT to add to change things without
you calling a consensus. And you have not, so there is NOTHING
for me to do except typo's and such.

The latest posts from those wanting changes have little or negligible
impact on the protocol and seem more to be disputing if something
should have been changed years ago. I can not find a single
item that was not discussed on the WG list prior to the
changes - can you? And those posts that want new items (GET-CAPABILITY
+ CALSCALE for example) are NOT on the item list in SF, so per
your and Ned's instructions to me -  I and not add them.

On IMC.ORG there are 12,213 total emails in the archives.
(I simply counted the number of lines that started
with 'Subject:') so it can't be that far off. I looked
in 'current archive' and 'old archive', are there more?

Where are the other 35,787 WG emails you talked about above?
Perhaps those are the source of confusion? I remember using
Bruce's archive in the past and noticed that non-WG calendaring
email was in his archive (which is why I stopped using it) - but
there were just a few so I do not see that as accounting for
the the 35 thousand extra emails.

--

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

              We Do Standards - You Need Standards
--=_alternative 005CE06785256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 12:11:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13324 for ; Wed, 5 Nov 2003 12:11:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GsrkT088907 for ; Wed, 5 Nov 2003 08:54:53 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Gsrl2088906 for ietf-calendar-bks; Wed, 5 Nov 2003 08:54:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GsqkT088901 for ; Wed, 5 Nov 2003 08:54:52 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <200311051633.27562.matthias.laabs@web.de> To: Matthias Laabs Cc: ietf-calendar@imc.org Subject: Re: How to define a CALSCALE? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Nov 2003 11:48:56 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/05/2003 11:54:47 AM, Serialize complete at 11/05/2003 11:54:47 AM Content-Type: multipart/alternative; boundary="=_alternative 005C070E85256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C070E85256DD5_= Content-Type: text/plain; charset="US-ASCII" Matthias asked on 11/05/2003 10:33:27 AM: > I am interested in writing a CALSCALE for JALALI(persian) calendar. Where can > I find information on how to write or where to propose it. Is the Gregorian > CALSCALE defined somewhere? Start with RFC 2445, Section 4.7.1 Calendar Scale for the actual property. From there you will need to also look at the DATE (Section 4.3.4 Date) bits and maybe the DATE-TIME (Section 4.3.5 Date-Time) bits so they are correctly defined for JALLAI. (Im assuming the time scales are the same...) Finally you will need to look at any necessary changes for the recurrence grammar (Section 4.3.10 Recurrence Rule) bits to define the correct grammar sub-parts. That is, you will want to adjust stuff like BYDAY values of "shanb", "yeksh", etc. and make sure the limits on values is adjusted accordingly. Once you've done this, you write it up using the RFC template for drafts and submit it for review. More detailed info can be found at http://www.rfc-editor.org/howtopub.html 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 005C070E85256DD5_= Content-Type: text/html; charset="US-ASCII"
Matthias asked on 11/05/2003 10:33:27 AM:
> I am interested in writing a CALSCALE for JALALI(persian) calendar. Where can
> I find information on how to write or where to propose it. Is the Gregorian
> CALSCALE defined somewhere?
Start with RFC 2445, Section 4.7.1 Calendar Scale for the actual property.  

From there you will need to also look at the DATE (Section 4.3.4 Date) bits and maybe the DATE-TIME (Section 4.3.5 Date-Time) bits so they are correctly defined for JALLAI.  (Im assuming the time scales are the same...)

Finally you will need to look at any necessary changes for the recurrence grammar (Section 4.3.10 Recurrence Rule) bits to define the correct grammar sub-parts.  That is, you will want to adjust stuff like BYDAY values of "shanb", "yeksh", etc. and make sure the limits on values is adjusted accordingly.

Once you've done this, you write it up using the RFC template for drafts and submit it for review.  More detailed info can be found at http://www.rfc-editor.org/howtopub.html

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 005C070E85256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 12:23:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13655 for ; Wed, 5 Nov 2003 12:23:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5H4NkT089899 for ; Wed, 5 Nov 2003 09:04:23 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5H4NoB089898 for ietf-calendar-bks; Wed, 5 Nov 2003 09:04:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5H4JkT089893 for ; Wed, 5 Nov 2003 09:04:21 -0800 (PST) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Mailing list still can be active MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Wed, 5 Nov 2003 12:04:31 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/05/2003 12:04:23 PM, Serialize complete at 11/05/2003 12:04:23 PM Content-Type: multipart/alternative; boundary="=_alternative 005DCC3085256DD5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DCC3085256DD5_= Content-Type: text/plain; charset="US-ASCII" For those of you who still need to get answers, the mailing list can stay active even though the working group closes. That is common practice. Just an FYI --=_alternative 005DCC3085256DD5_= Content-Type: text/html; charset="US-ASCII"
For those of you who still need to get answers, the mailing list can stay active even though the working group closes.  That is common practice.  Just an FYI --=_alternative 005DCC3085256DD5_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 12:31:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13943 for ; Wed, 5 Nov 2003 12:31:09 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HFekT090372 for ; Wed, 5 Nov 2003 09:15:40 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5HFeoC090371 for ietf-calendar-bks; Wed, 5 Nov 2003 09:15:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA5HFdkT090366 for ; Wed, 5 Nov 2003 09:15:39 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003110512295802679 ; Wed, 05 Nov 2003 12:29:58 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Nov 2003 12:12:42 -0500 Message-ID: <3FA92F8A.3010707@centive.com> Date: Wed, 05 Nov 2003 12:12:42 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: Matthias Laabs Subject: Re: How to define a CALSCALE? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2003 17:12:42.0664 (UTC) FILETIME=[06067280:01C3A3C0] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Finally you will need to look at any necessary changes for the > recurrence grammar (Section 4.3.10 Recurrence Rule) bits to define the > correct grammar sub-parts. That is, you will want to adjust stuff > like BYDAY values of "shanb", "yeksh", etc. and make sure the limits > on values is adjusted accordingly. Or you might consider specifying that BYDAY still use the Gregorian values for days of the week, to reduce the complexity for implementers who want to support both scales. It'd be annoying to humans reading the Persian text/calendars, but that's going to be less common. I imagine they'd rather have more choice of implementations to use. (There is a 1-1 correspondence, right? Shanb is always the same as Sunday, yeksh the same as Monday, etc.? I can imagine a calendar where the last day or two of the year is not part of any week, and the week always gets reset on the first day of the year; such a calendar scale couldn't use the Gregorian names, since there wouldn't be a 1-1 correspondence.) -- /===============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===============================================================| |"This year, only 28 percent of all Americans will prepare their| |own tax returns, according to a voice in my head that invents | |accurate-sounding statistics." -- Dave Barry | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Nov 5 13:05:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15130 for ; Wed, 5 Nov 2003 13:05:01 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HpekT092485 for ; Wed, 5 Nov 2003 09:51:40 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Hpewj092484 for ietf-calendar-bks; Wed, 5 Nov 2003 09:51:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HpdkT092477 for ; Wed, 5 Nov 2003 09:51:39 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA5HpX6M004059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Nov 2003 09:51:34 -0800 Message-ID: <3FA9389F.9060704@Royer.com> Date: Wed, 05 Nov 2003 10:51:27 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-e: 8.22 MULTIPART Property ABNF References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070909090201060309050707" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070909090201060309050707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In looking at the CAP-12-e draft I see in Section 8.22 MULTIPART > Property the following: > > 8.22 MULTIPART Property > > Property Name: MULTIPART > [Snip, snip] > Formal Definition: The property is defined by the following notation: > > > name = "MULTIPART" other-params ":" text *( "," text) CRLF Now 'mname' - fixed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070909090201060309050707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MTc1MTI3WjAjBgkqhkiG9w0BCQQxFgQUmBP6UOYzm7Ph/XNEMyfv MByYsMwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAd+TIzxF/NRqHXkNcVoN6VpLNOq5gf76rkx3YrQbPN0zsbKnL4yXXUIRqXZrHHet+ b5VUueDrU3C+CzktoUtZI+SVxJT5bR/n0SxhDaa6bOz0gbRAna8gRO5hlbwJCopBionWHjFx aNGdd/wCAdcpNU0LNzd5Bv6anPZfbLDZ2Kyi1kc+srvBvo1V/8XN0t6SA0nHoDxH78WyORO8 yF6FeyTjeh/FJW+LqXsYh2DhUYNnbnHadtVsmhE99Fq+e22x4JWKmnC/95IiQj1b9qRhCfuZ Dpiaw2I/RzEae+DU6su+AsVjT8Q3/uPdQMOjdYPZ13HttUjpv4K0DqSEMg3GugAAAAAAAA== --------------ms070909090201060309050707-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 13:05:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15146 for ; Wed, 5 Nov 2003 13:05:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HrikT092598 for ; Wed, 5 Nov 2003 09:53:44 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Hriem092597 for ietf-calendar-bks; Wed, 5 Nov 2003 09:53:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HrhkT092592 for ; Wed, 5 Nov 2003 09:53:43 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA5Hre6M004073 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Nov 2003 09:53:41 -0800 Message-ID: <3FA9391F.4040506@Royer.com> Date: Wed, 05 Nov 2003 10:53:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: 'text' not in ABNF References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050200060101040609040703" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050200060101040609040703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I added: text = ; As defined in [iCAL]. To the fist usage (id-param) ABNF Fixed. Bruce_Kahn@notesdev.ibm.com wrote: > > In trying to answer a question for someone I tried to show them where > in CAP-12-e we had ABNF for 'text' but I can find none nor any > reference to whose 'text' definition is being used. This should be > included in CAP-12-e for completeness in accurately building a CAP > parser. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050200060101040609040703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MTc1MzM1WjAjBgkqhkiG9w0BCQQxFgQUUzyQ3GijRxSB1LbaKgy0 DNDZaO4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAADdvWbWRM99qEaIBHaj3uJyE/RL/rRRPwIvgw6sKt3nB/rdHCjar7/ytldO6ZmTZ 6ipWXEQVAPlav9jM1pn51Uh7o1DY1CgOw0H9yZp+t8/vRV03cejUCEHsfRtTF1iZ9hPGnHHh zPIVsnj985f12GlqRBuLOi73xxtvofejiDFitBSrJ6qjZ4scyurDVDdiaP4bQox/Y2H+65Jt h2IuxVpc2mZtcief5fFrLRzvBwO6y0pBuD4G2wVi5mq1kYLcydRv5vbkiILduynTNIFCpMQE 1PME+yzMh3CeKkOKQmGKQPZ5i1IcqFX5XJklqUGRnZccYTlRz8A60edUT0hyyAAAAAAAAA== --------------ms050200060101040609040703-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 13:12:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15548 for ; Wed, 5 Nov 2003 13:12:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5I0PkT092822 for ; Wed, 5 Nov 2003 10:00:25 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5I0PCa092821 for ietf-calendar-bks; Wed, 5 Nov 2003 10:00:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5I0NkT092816 for ; Wed, 5 Nov 2003 10:00:23 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA5I0K6M004130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Nov 2003 10:00:21 -0800 Message-ID: <3FA93AAE.9090401@Royer.com> Date: Wed, 05 Nov 2003 11:00:14 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000406020602040908000002" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000406020602040908000002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Then I have your permission to send the private email to this list? Bruce_Kahn@notesdev.ibm.com wrote: > > Doug claimed on 11/04/2003 09:37:01 PM: > > And the same > with > > Bruce (email only), I have reached out trying to find ways of trying > > to resolve issues, you (and others) did not respond. at all. > > This is patently false with respect to me. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000406020602040908000002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MTgwMDE0WjAjBgkqhkiG9w0BCQQxFgQUn2+6gvh1qpcWNetwmOfn dtqfgD8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAQdCxYhFFVBy86Ic6EaoVf0iADi8NyoK0/dxmM2bmNN12oLui6ShoCF+uj3U6gV+y c/+ovHZhea1Dw7vEwU750YFtNMiYLb7Qbfp1VuB1Ll8PyE6EuRzf7yr3EdCYTCIlTxZqqcrm 3ad8eGtmiCNl1diD1wSsz5IJcYHi0MSPpCOJ/wI2TQ7XxDQl9768BuI0pxjLgqqtPC4lns3n uRSVL3uD/LzPT58myW9Ov/kSKtkWjlq7w2Uybr0iBQ1um+Aaiaqdi2dd0LYZpILJ3Qr75qc/ QVG96uStVz4QEmFGpWK8qVq9L82nPaRcBISSG6hyooOpP43rs/Ep/VW11lXq9QAAAAAAAA== --------------ms000406020602040908000002-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 13:20:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15757 for ; Wed, 5 Nov 2003 13:20:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5I4dkT092966 for ; Wed, 5 Nov 2003 10:04:39 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5I4dlT092965 for ietf-calendar-bks; Wed, 5 Nov 2003 10:04:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from gw.provo.novell.com (gw.provo.novell.com [137.65.47.29]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5I4ckT092960 for ; Wed, 5 Nov 2003 10:04:38 -0800 (PST) (envelope-from cjohnson@gw.novell.com) Received: from PROVO7-MTA by gw.provo.novell.com with Novell_GroupWise; Wed, 05 Nov 2003 11:01:36 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Beta Date: Wed, 05 Nov 2003 11:05:56 -0700 From: "Craig Johnson" To: Subject: Re: When to publish -12 - VFREEBUSY Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD6884D14.0__=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=__PartD6884D14.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Doug responded: > CJohnson Wrote >> !!! The WG standard for making a request for free-busy time is with >> the VFREEBUSY object. !!! RFC 2445, p. 58: > >It does and in -exactlyt- the same way - by the CUA and we added by the CS. I wish Doug were correct. But CAP-12e has no provision that permits the CUA to make a free-busy request using the VFREEBUSY component and get a direct response. * It's not in Section 10.12.1. That section attempts to define how to get VFREEBUSY components using a VQUERY. * It's not done using iTIP (CMD:CREATE, METHOD:REQUEST). All [iTIP] messages are deposited in the CS in the UNPROCESSED state. The CUA simply gets a "success" response. (Section 10.4). Once again, I assert: CAP does not support this WG's established definition (standard) for requesting free-busy information using the VFREEBUSY component ... specifically, in a real-time direct request/response CAP exchange. This point was made in a previous discussion thread which, after some give-and-take, eventually concurred on the issue. Consequently, we thought this would be accomodated in CAP-12; but, for reasons unknown it didn't show up. A solution has been proposed several times. What criteria has this issue not met to be incorporated into CAP? What objections can there be for CAP to conform with and facilitate this WG's own standards? C Johnson --=__PartD6884D14.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Doug responded:
 
> CJohnson Wrote
>> !!! The = WG standard for making a request for free-busy time is with
>> = the VFREEBUSY object. !!!  RFC 2445, p. 58:
>
>It does = and in -exactlyt- the same way - by the CUA and we added by the CS.
I wish Doug were correct.  But CAP-12e has no provision = that permits
the CUA to make a free-busy request using the VFREEBUSY = component 
and get a direct response.
 
=97 It's not in Section 10.12.1.  That section attempts to = define how to get
    VFREEBUSY components using a VQUERY.
 
=97 It's not done using iTIP (CMD:CREATE, METHOD:REQUEST).  = All [iTIP]
    messages are deposited in the CS in the UNPROCESSED= state.  The CUA
    simply gets a "success" response.  (Section = 10.4).
 
Once again, I assert:
CAP does not support this WG's established definition (standard) = for
requesting free-busy information using the VFREEBUSY component = ... 
specifically, in a real-time direct request/response CAP = exchange.
 
This point was made in a previous discussion thread = which, after
some give-and-take, eventually concurred on the = issue. Consequently,
we thought this would be accomodated in CAP-12; but, for = reasons
unknown it didn't show up.  A solution has been = proposed several times.
 
What criteria has this issue not met to be incorporated into = CAP?  What
objections can there be for CAP to conform with and facilitate this = WG's
own standards?
 
C Johnson
--=__PartD6884D14.0__=-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 13:28:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16049 for ; Wed, 5 Nov 2003 13:28:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5IFUkT093769 for ; Wed, 5 Nov 2003 10:15:30 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5IFUcu093768 for ietf-calendar-bks; Wed, 5 Nov 2003 10:15:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5IFSkT093763 for ; Wed, 5 Nov 2003 10:15:29 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA5IFJ6M004531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Nov 2003 10:15:24 -0800 Message-ID: <3FA93E2E.9040704@Royer.com> Date: Wed, 05 Nov 2003 11:15:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070805090902080309010405" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070805090902080309010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > I appreciate your comments Doug. However, Ned nor I ever stated it > was ok to flood inbaskets with email in order to stop people from > raising objections to items on the draft. The word FLOOD was not used. The topic of answering each and every email was discussed so that we did not keep getting those posts about questions not answered years earlier even when the questions were not well researched. When no one answers those questions then there is always someone saying 'hay this was not addressed' and we did discuss that the only way to close those issues. Review the non-RECURRENCE-ID questions since SF meeting. The vast majority were alreay in the draft when the email was sent claiming the issue was not resolved. Aside from the RECURRENCE-ID issue which went astray, who was going to answer those questions posted? And I have never sent email in order to stop anyone. I have sent email in order to get people to research their questions first as it takes time to research each question. And as you have observed on this list unanswered questions can start a debate to solve an issue that was ether already covered in the draft or never in the requirements. We also discussed how you would declare old issues closed so that we could move on. And then only reopen them if there was an overwhelming consensus. Please do so. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070805090902080309010405 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MTgxNTEwWjAjBgkqhkiG9w0BCQQxFgQU7BfGt7he9obe2UXQsg/j mI+0es4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAEzThcIs6iieiNLFCxgrYmHCL5jl83524Wd9njUOLKLE2qWOj4V8mQH6GNnqHakvf szTDE1csvwuNt/4iHHGrKHcPbibyDCuN3K8cYq/mShY9REVoyPlPOr7YNVDF/gkK5qjsa0aG r+cWks09BLOQ1nJWfWdm0u3eA74dzDu9Gf2pYL3AF7JGQlqZ1qfFZkX/SjGkunGMLhW9HPSz QBkoAC9MLnuH+565O8sc/eMn5e+jY7fASKc5nLtHQaXI8JifBYzGKPZfByIRKqItRKBixRAM XeP+vCFSHfOhO/ui0Ma2Qedy1hmPJW8PcV4X2CzYx1f80Io1syo5KHBSbS6zjwAAAAAAAA== --------------ms070805090902080309010405-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 13:49:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16781 for ; Wed, 5 Nov 2003 13:49:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5IbDkT094561 for ; Wed, 5 Nov 2003 10:37:13 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5IbDCB094560 for ietf-calendar-bks; Wed, 5 Nov 2003 10:37:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5IbCkT094554 for ; Wed, 5 Nov 2003 10:37:12 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA5Ib66M004927 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 5 Nov 2003 10:37:08 -0800 Message-ID: <3FA9434D.1010504@Royer.com> Date: Wed, 05 Nov 2003 11:37:01 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: When to publish -12 - VFREEBUSY References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040204050505060100010705" X-Royer.com-MailScanner-Information: Please contact the ISP for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040204050505060100010705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Craig Johnson wrote: > Doug responded: > > > CJohnson Wrote > >> !!! The WG standard for making a request for free-busy time is with > >> the VFREEBUSY object. !!! RFC 2445, p. 58: > > > >It does and in -exactlyt- the same way - by the CUA and we added by=20 > the CS. > I wish Doug were correct. But CAP-12e has no provision that permits > the CUA to make a free-busy request using the VFREEBUSY component > and get a direct response. Nor does iTIP - it has to be processed by the CUA - correct? Currently the only way to send a message is iMIP, that does not generate an auto reply unless your MTA has a CUA built into it. > =97 It's not in Section 10.12.1. That section attempts to define how to= get > VFREEBUSY components using a VQUERY. > =97 It's not done using iTIP (CMD:CREATE, METHOD:REQUEST). All [iTIP] > messages are deposited in the CS in the UNPROCESSED state. The CUA > simply gets a "success" response. (Section 10.4). Which is exactly how iMIP does it to your mailbox to later be processed by your CUA - correct? --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040204050505060100010705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA1MTgzNzAxWjAjBgkqhkiG9w0BCQQxFgQUpfuuxFSqpcb7GAPeWDfz h+UCbjEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEABBmKoI4jfVTKUld5Wn4BBYG29849b/dT/VbY1L6IZr1/TAnHBVCcOhyEnTEAoD8f WQpmkSE82XlM8Y7BsxRiWzSN4Wj5wAW9ImUKWej4i2Do5UdcL5y8nDP5EPZMFJ76DZU2O0sv gfSvK/UwxLR45mCbXaQkMnw4CIIstic/77vcVTmfJesbt8GJwSP9pfmJ3F0o+HFBiAjaeR/Q D2Asdt9n3KIVdzSnc93ovTe8xKJlxrKuc6L5C1PJEQ2QxE3WjhBw21oxhhNJXID10DSEUbbk 1xDjIuDIiSBRtTbx8lcboh3nfzKywRiDFJboCO4UloNj4eBCkHMVNbwPhh0z/AAAAAAAAA== --------------ms040204050505060100010705-- From owner-ietf-calendar@mail.imc.org Wed Nov 5 17:09:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26708 for ; Wed, 5 Nov 2003 17:09:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Lg3kT001730 for ; Wed, 5 Nov 2003 13:42:03 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5Lg313001729 for ietf-calendar-bks; Wed, 5 Nov 2003 13:42:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from bikini.cac.washington.edu (bikini.cac.washington.edu [128.208.94.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5Lg2kT001724 for ; Wed, 5 Nov 2003 13:42:02 -0800 (PST) (envelope-from slh@bikini.cac.washington.edu) Received: from localhost (slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) with ESMTP id hA5Lfw306743 for ; Wed, 5 Nov 2003 13:41:58 -0800 (PST) Date: Wed, 5 Nov 2003 13:41:58 -0800 From: slh@bikini.cac.washington.edu To: ietf-calendar@imc.org Subject: Re: CAP-12-e: 8.22 MULTIPART Property ABNF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: yes, I believe I sent out a note for both -9 and -10 about this... On Wed, 5 Nov 2003 Bruce_Kahn@notesdev.ibm.com wrote: > In looking at the CAP-12-e draft I see in Section 8.22 MULTIPART Property > the following: > > 8.22 MULTIPART Property > > Property Name: MULTIPART > [Snip, snip] > Formal Definition: The property is defined by the following notation: > > > name = "MULTIPART" other-params ":" text *( "," text) CRLF > > so this section is defining an ABNF for 'name' to be used elsewhere. But > the next section 8.23 NAME Property says: > > 8.23 NAME Property > > Property Name: NAME > [Snip, snip] > Formal Definition: The property is defined by the following notation: > > name = "NAME" nameparam ":" text CRLF > > which appears to define the same ABNF value. This is not goodness (or at > least it should be using the "/=" instead of "=" if it were an extension > of name) > > I suspect that the ABNF under Section 8.22 just needs touching up and any > references to MULTIPART need to be santiy checked. > > Bruce > =========================================================================== > Bruce Kahn INet: > Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law.. From owner-ietf-calendar@mail.imc.org Wed Nov 5 18:20:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00422 for ; Wed, 5 Nov 2003 18:20:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5N3qkT004834 for ; Wed, 5 Nov 2003 15:03:52 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5N3qxH004833 for ietf-calendar-bks; Wed, 5 Nov 2003 15:03:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5N3pkT004828 for ; Wed, 5 Nov 2003 15:03:51 -0800 (PST) (envelope-from CJohnson@MyRealBox.com) Received: from CraigP4 cjohnson@smtp-send.myrealbox.com [137.65.12.67] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 3.44 $ on Novell NetWare; Wed, 05 Nov 2003 16:03:53 -0700 Message-ID: <000d01c3a3f1$146bc9c0$430c4189@CraigP4> From: "Craig Johnson MRB" To: Subject: Re: When to publish - 12 - VFREEBUSY Date: Wed, 5 Nov 2003 16:03:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C3A3B6.67F52400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C3A3B6.67F52400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doug Wrote >cjohnson wrote >> I wish Doug were correct. But CAP-12e has no provision that permits >> the CUA to make a free-busy request using the VFREEBUSY component >> and get a direct response. > >Nor does iTIP - it has to be processed by the CUA - correct? See response below. >> - It's not in Section 10.12.1. That section attempts to define how to = get >> VFREEBUSY components using a VQUERY. >> - It's not done using iTIP (CMD:CREATE, METHOD:REQUEST). All [iTIP] >> messages are deposited in the CS in the UNPROCESSED state. The CUA >> simply gets a "success" response. (Section 10.4). > >Which is exactly how iMIP does it to your mailbox to later be >processed by your CUA - correct? Are you suggesting that only a CUA understands a VFREEBUSY request and=20 only a CUA can respond to it? Are you suggesting that a Calendar Store = is not capable of handling a VFREEBUSY request and providing a direct response? If so, I respectfully but strongly disagree. I can think of no = compelling reason=20 to impose such a limitation on the CS. I can think of many to the = contrary. To refocus on the issue: CAP does not support this WG's established definition (standard) for=20 requesting free-busy information using the VFREEBUSY component ...=20 and provide a direct real-time response. (RFC 2445, p 58) This point was made in a previous discussion thread which, after some give-and-take, eventually concurred on the issue. We anticipated=20 this would be included in CAP-12; but, for reasons unknown it was left out. A proposed solution has been provided several times. It was discussed, there was concurrence, and solution provided. What = criteria=20 has not been met for this issue to be incorporated into CAP? What = objections=20 can there be to have CAP conform with this WG's own standards? C Johnson ------=_NextPart_000_000A_01C3A3B6.67F52400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Doug=20 Wrote
>cjohnson wrote
>> I=20 wish Doug were correct. But CAP-12e has no provision that = permits
>>=20 the CUA to make a free-busy request using the VFREEBUSY = component
>>=20 and get a direct response.
>
>Nor does=20 iTIP - it has to be processed by the CUA - correct?
 
See response = below.

>> - It's not in Section = 10.12.1. That=20 section attempts to define how to get
>> VFREEBUSY components = using a=20 VQUERY.
>> - It's not done using iTIP (CMD:CREATE, = METHOD:REQUEST). All=20 [iTIP]
>> messages are deposited in the CS in the UNPROCESSED = state.=20 The CUA
>> simply gets a "success" response. (Section=20 10.4).
>
>Which is exactly = how iMIP=20 does it to your mailbox to later be
>processed by your CUA -=20 correct?

 
Are you suggesting that only a CUA = understands=20 a VFREEBUSY request and
only a CUA can respond to it?  Are = you suggesting that a Calendar Store is not
capable of handling a VFREEBUSY request = and=20 providing a direct response?

If so, I respectfully but strongly=20 disagree.  I can think of no compelling reason
to impose such a limitation on the = CS.  I=20 can think of many to the contrary.
 
To refocus on the issue:
 
CAP does not support this WG's = established=20 definition (standard) for
requesting free-busy information using = the=20 VFREEBUSY component ... 
and provide a direct=20 real-time response.  (RFC 2445, p 58)
 
This point was made in a = previous=20 discussion thread which, after
some give-and-take, eventually=20 concurred on the issue. We anticipated
this would be included in = CAP-12; but,=20 for reasons unknown it was left
out.  A proposed=20 solution has been provided several times.
 
It was discussed, there was = concurrence, and=20 solution provided.  What criteria
has not been met for this issue to = be=20 incorporated into CAP?  What objections
can there be to=20 have CAP conform with this WG's own = standards?
 
C = Johnson
------=_NextPart_000_000A_01C3A3B6.67F52400-- From owner-ietf-calendar@mail.imc.org Thu Nov 6 09:25:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09983 for ; Thu, 6 Nov 2003 09:25:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6E8okT011116 for ; Thu, 6 Nov 2003 06:08:50 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA6E8okB011115 for ietf-calendar-bks; Thu, 6 Nov 2003 06:08:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6E8mkT011107 for ; Thu, 6 Nov 2003 06:08:48 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA6E8b2S019771 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 6 Nov 2003 06:08:41 -0800 Message-ID: <3FAA55DF.7060701@Royer.com> Date: Thu, 06 Nov 2003 07:08:31 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Auto reply and VFREEBUSY References: <000d01c3a3f1$146bc9c0$430c4189@CraigP4> In-Reply-To: <000d01c3a3f1$146bc9c0$430c4189@CraigP4> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090501010700040100030609" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090501010700040100030609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Craig Johnson MRB wrote: > Doug Wrote > >cjohnson wrote > >> I wish Doug were correct. But CAP-12e has no provision that permits > >> the CUA to make a free-busy request using the VFREEBUSY component > >> and get a direct response. > > > >Nor does iTIP - it has to be processed by the CUA - correct? > > See response below. > > >> - It's not in Section 10.12.1. That section attempts to define how > to get > >> VFREEBUSY components using a VQUERY. > >> - It's not done using iTIP (CMD:CREATE, METHOD:REQUEST). All [iTIP] > >> messages are deposited in the CS in the UNPROCESSED state. The CUA > >> simply gets a "success" response. (Section 10.4). > > > >Which is exactly how iMIP does it to your mailbox to later be > >processed by your CUA - correct? > > Are you suggesting that only a CUA understands a VFREEBUSY request > and only a CUA can respond to it? The new limitation of the auto reply CAP mode is that the requester will not get the CU's blocked out time, but the CALID's busy time. In iTIP/iMIP mode the requester can get the CU's blocked out time as the CUA knows about other of the CU's calendars. If we make everything always auto reply, then we can no longer get the CU's blocked out time (When it differs from the one specific calendar the requester connected to with CAP ). Plus not all CS's can respond (reasons given in previous post). I am suggesting that the 'auto' response (which is a new idea in CAP) be done with CREATE/VFREEBUSY+REPLY. And that the CUA non-'auto' response be done as it is now with iTIP/iMIP in the CUA (data stored in the CS) so that the existing iTIP flow not be altered. Currently the iTIP/iMIP method gets you the CU's busy time as determined by the CUA. > Are you suggesting that a Calendar Store is not > capable of handling a VFREEBUSY request and providing a direct response? A VFREEBUSY/REQUEST is not auto respond to now and is not a real time reply in 2445, 2446, or 2447. So why break CUA's that ADD the users blocked out time or merge multiple blocked out times from multiple different calendars from working correctly? There has been no requirement that what the CUA sent matched 100% to items any user can find in a named calendar. A simple example could be that the CUA always adds in the company holiday schedule calendar to the users busy time. In the email reply to your post I listed several conditions and showed how unconditionally changing the iTIP flow from the CUA to the CS using the text you provided would break some implementations. (Not all CS's can expand recurrence instances so they can not auto reply.) > If so, I respectfully but strongly disagree. I can think of > no compelling reason to impose such a limitation on the CS. > I can think of many to the contrary. > > To refocus on the issue: > > CAP does not support this WG's established definition (standard) for > requesting free-busy information using the VFREEBUSY component ... > and provide a direct real-time response. (RFC 2445, p 58) RFC 2445 does not specify real time processing of VFREEBUSY and the words 'real-time' are NOT in that section or any other section of 2445, or 2447. And its usage in 2446 is not on point, except for enabling CAP (unnamed) as the new real-time transport. Real time is what CAP adds. > This point was made in a previous discussion thread which, after > some give-and-take, eventually concurred on the issue. We anticipated > this would be included in CAP-12; but, for reasons unknown it was left > out. A proposed solution has been provided several times. Real time VFREEBUSY calculations and replies are in -12. It was not missed or skipped. Your proposal was incomplete and failed to take into account several items (see my reply to your post). You indicated that you would digest my reply and comment. And I hoped fill in the missing conditions that you did not take into account in your proposal. > It was discussed, there was concurrence, and solution provided. > What criteria has not been met for this issue to be incorporated > into CAP? What objections can there be to have CAP conform > with this WG's own standards? There was more than one proposal sent and there were questions asked that still have not been answered about those proposals. Again CAP does have real time VFREEBUSY replies which is new to CAP and did not exist in 2445, 2446, or 2447, The text put in CAP allows for the new auto reply by the CS. And the text in CAP allows for exactly the same iTIP flow now used. Given that the CUA is what puts data into a CS and the CUA is what gets data out of a CS, the CUA can pick iTIP/iMIP (CU busy time) mode or the new auto-responce CAP (CALID busy time) mode . -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090501010700040100030609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA2MTQwODMxWjAjBgkqhkiG9w0BCQQxFgQUlXkhg1LZ+h5CRrtyYOPk awuKiEowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAmUakAWibVKx/i4/vgZAoBbjkNb/C18WDFF4GQE2WmG5vG/JwCFKAOncQ6UcrWv2F mk7SjPoxIRVPAQZnTh6Q0HQYo+7L74FC8sarkNW1x/MrUBd/qglkLnGEphAXPFmlhZ7X566+ X+6FwcvW1bTVpFMjO6Mc88MR9GqGLtF4CyQ3HiHl5beP/v0RVc/4FYKwgu8qW+91N8HGtwJs x4vgQHPLAnLYqKSdatriWvQivs0O+ny/gTCAtZ0aKm2JdZl5VxLsv8ruvKPHVswBk8Lg8mFR TbqW5KPK6+zB7MYF4TcrRxPcGMWqoHFSvL/szF3QRsr/Uf0DrgG1rc5jvY+ufQAAAAAAAA== --------------ms090501010700040100030609-- From owner-ietf-calendar@mail.imc.org Fri Nov 7 12:15:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24045 for ; Fri, 7 Nov 2003 12:15:31 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7GllkT043418 for ; Fri, 7 Nov 2003 08:47:47 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7Gllon043417 for ietf-calendar-bks; Fri, 7 Nov 2003 08:47:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from trout.cpsr.org (trout.cpsr.org [66.180.229.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7GlkkT043403 for ; Fri, 7 Nov 2003 08:47:46 -0800 (PST) (envelope-from nsb@guppylake.com) Received: from guppylake.com (trout [66.180.229.5]) by trout.cpsr.org (8.12.8p2/8.12.8) with ESMTP id hA7GlAta085420; Fri, 7 Nov 2003 08:47:26 -0800 (PST) (envelope-from nsb@guppylake.com) Date: Fri, 7 Nov 2003 11:48:18 -0500 Subject: Re: Status of the CALSCH working group Content-Type: multipart/alternative; boundary=Apple-Mail-86--277814710 Mime-Version: 1.0 (Apple Message framework v552) Cc: pregen@egenconsulting.com, ietf-calendar@imc.org To: Satya Vempati From: Nathaniel Borenstein In-Reply-To: <000401c3a330$aa445af0$6d9012c0@red.iplanet.com> Message-Id: <306166D6-1142-11D8-A05D-000A9571873E@guppylake.com> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-86--277814710 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Tuesday, November 4, 2003, at 07:06 PM, Satya Vempati wrote: > Would it be possible to get someone like Nathaniel Borenstein to take > the role of a co-editor (if he is interested)? It would help to have a > seasoned veteran of the IETF process to help move things forward. Well, I guess this is my clue to stop lurking.... so I'll apologize in advance for the length of this message. As many of you know, I have been coming up to speed on the CALSCH working group for several months now, and have expressed a willingness to try to help. However, in the spirit of the Hippocratic oath -- "First, do no harm" -- I have been slow to volunteer for a particular role, but I am definitely ready to do so now. However, I'd like to take a step back and point out where we are in the larger picture and where we need to go. The current debates all center around one particular document, the CAP document, which Doug is struggling manfully to complete. Completing the CAP draft would be a great thing, but let's not kid ourselves about where it leaves us: the absolute best thing that can result from the current efforts is the publication of an RFC that *might* be approved as a Proposed Standard, thereby catching up to most of the rest of the calendaring-related documents, none of which, I believe, have gotten past that "first step" in the standardizations process. There's still a long, long way to go, and I know that many of you are rather discouraged, given how long this project has been under way. Standards take a long time, and progress in calendaring and scheduling at the IETF has been particularly tortuous. I know that some good people have simply burnt out along the way, and I'm not (deliberately) volunteering to be the next one. I don't want to jump in without a path and plan to success, so I'm going to be a tad brutal in the next paragraph, though I intend no offense or disrespect to anyone who has been working on this challenging process. It is my opinion that ALL of the CALSCH documents -- not just CAP -- need a lot of work. A successful standard needs to be completely free of ambiguity. You don't get there simply by tending to the most urgently yelled-about issues, you get there by comprehensively looking for ambiguities and using extremely clear, consistent, and conscious language for all of the specifications, especially with regard to the MUST/SHOULD/MAY kinds of language and the existence of a complete authoritative ABNF grammar of which the text is really only an elucidation. If I'm right, getting CAP out the door could be a pyrrhic victory. If it were up to me -- and I've been nominated to join the IAB, for whatever that's worth -- I don't think I could support advancing CAP to proposed standard as it stands, but I'm notoriously picky and wouldn't have supported moving several of the other documents to that stage, either, had I been involved at the time. I want a lot more clarity and a lot less ambiguity, or we're going to start having proposed standards with incompatible implementations. In any event, even if my requirements are too demanding for "Proposed" status, I predict that my concerns will be major problems later in moving the documents to Draft and Full standard status. (For reference, it took us a long time to get MIME to Proposed status, but the process was *relatively* painless and mechanical from then on because there really weren't that many ambiguities left.) Given this perspective, there's an argument to be made that the logical thing to do is to "finish" the CAP document (for some careful definition of "finish") and then open a whole new round of revisions to the CALSCH documents, including CAP. I would be willing to serve as a document editor for such a round of revisions. But in the meantime, we have to either put CAP to bed or put it on hold for a whole new round. One of the reasons I've been lurking quietly is that I had hoped to postpone my more active involvement until CAP was finished, but I now think that putting our recent discussion in the context of the larger needs of CALSCH might actually help us figure out how to finish CAP. To put it in perspective: The CAP document describes an early stage protocol with no functionally interoperating implementations (that I know of). This means that it WILL have mistakes in it -- there's no substitute for building interoperable code for fleshing out those mistakes. So we don't have to believe that CAP is perfect for us to sign off on it, because we know that it will simply provide a basis for further experiments toward the goal of a fully interoperable protocol. Remembering that perfection is not a requirement should be helpful. Instead of perfection, I think we should be pursuing a somewhat more modest goal, which is to identify and correct any deficiencies in the current CAP spec that can be reasonably anticipated to cause major headaches for that next round of standardization efforts. It is my preference to confine my own comments on CAP to that category of problems that could significantly complicate the efforts that I am volunteering to help lead for the next round of CALSCH document revisions. Thus, with that ridiculous amount of prologue -- and with gratitude to anyone who has read this far -- I now offer my own opinions about what we need to fix to put this version of CAP to bed. There are three things that I regard as *potential* showstoppers, though not difficult ones to fix: Versioning: The CAP-VERSION property as currently defined is simply not adequate to allow us the possibility of gracefully introducing incompatible changes in future versions. As I contemplate an involvement in such future refinements, I can't imagine a more "showstopping" problem than this one. FWIW, I speak from bitter experience: for those of you who don't realize it, "MIME-Version" has an inadequate definition that almost certainly precludes *any* future values other than 1.0. I would like to see CAP avoid the same mistake, as I think the cost would be much greater for CAP than it was for MIME. CALSCALE -- I would like to either see us add a capability specification for calendar scales and a special error code for unsupported calendar scales, or I would like someone to convince me that the absence of such scales isn't really a problem for future extensions. What we have right now tells us that there might be other calendar scales, but doesn't really tell an implementation how to behave if it encounters one. ABNF -- There simply must be a complete ABNF for a standards-track protocol, in my opinion. However, I'm also not convinced that releasing CAP as an Experimental RFC without such an ABNF would in any way impede CAP's progress in the market. In fact, publication as an Experimental RFC might well be the smartest, fastest track for closure on the current document. I could support publication as an experimental RFC if only my first two issues (CAP-VERSION and handling of unrecognized CALSCALE values) are resolved. There are a couple of more things I would really like to see cleaned up, though I can imagine publication (especially as Experimental) without fixing them: "SCOPING" -- The issue discussed as "SCOPING" on the list concerns me, but only as an easily-clarified ambiguity. It seems that sometimes when you say "SELECT VALARM" (or SELECT whatever), you want only the VALARM (or whatever), and sometimes you want the whole enclosing ical body, including the time zone, product-id, method, cal-scale, the whole kit and kaboodle. I can understand -- barely -- why you might sometimes NOT want the enclosing stuff, but surely you often do want it, so either we need to be crystal clear that "everything" (properly defined) is to be returned, or we need to provide two forms of the request to get the two kinds of return. VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems to me that there are several ambiguities here. I think that we must be clear about a requirement that servers MUST provide "currently accurate" freebusy information in response to an appropriate request. And I'm definitely confused about why one would want to permit the use of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the ITIP syntax for requesting this information. Finally, there are a couple of things that I am still confused about after months on the list. This doesn't necessarily mean there's a problem, but it certainly makes me nervous -- at the risk of sounding arrogant, if I haven't figured it out yet, I'm not optimistic that all implementors will "figure it out" in a compatible way: EXPAND and QUERYID -- I am having a hard time understanding how stored queries can be useful without search wildcards. Can anyone explain this to me? Alarms/SEQUENCE -- I remain confused: Can there be two identical objects in the same calendar? If not, we should clearly say so. Anyway, I apologize for the length of this message and for its appearance at such a late pre-Minneapolis moment, but since Satya has honored me with the suggestion that I might be of help, I thought I should try to lay out my current thinking as clearly as possible. I look forward to seeing as many as possible of you in Minneapolis! -- Nathaniel --Apple-Mail-86--277814710 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tuesday, November 4, 2003, at 07:06 PM, Satya Vempati wrote: Arial0000,0000,8080Would it be possible to get someone like Nathaniel Borenstein to take the role of a co-editor (if he is interested)? It would help to have a seasoned veteran of the IETF process to help move things forward. Well, I guess this is my clue to stop lurking.... so I'll apologize in advance for the length of this message. As many of you know, I have been coming up to speed on the CALSCH working group for several months now, and have expressed a willingness to try to help. However, in the spirit of the Hippocratic oath -- "First, do no harm" -- I have been slow to volunteer for a particular role, but I am definitely ready to do so now. However, I'd like to take a step back and point out where we are in the larger picture and where we need to go. The current debates all center around one particular document, the CAP document, which Doug is struggling manfully to complete. Completing the CAP draft would be a great thing, but let's not kid ourselves about where it leaves us: the absolute best thing that can result from the current efforts is the publication of an RFC that *might* be approved as a Proposed Standard, thereby catching up to most of the rest of the calendaring-related documents, none of which, I believe, have gotten past that "first step" in the standardizations process. There's still a long, long way to go, and I know that many of you are rather discouraged, given how long this project has been under way. Standards take a long time, and progress in calendaring and scheduling at the IETF has been particularly tortuous. I know that some good people have simply burnt out along the way, and I'm not (deliberately) volunteering to be the next one. I don't want to jump in without a path and plan to success, so I'm going to be a tad brutal in the next paragraph, though I intend no offense or disrespect to anyone who has been working on this challenging process. It is my opinion that ALL of the CALSCH documents -- not just CAP -- need a lot of work. A successful standard needs to be completely free of ambiguity. You don't get there simply by tending to the most urgently yelled-about issues, you get there by comprehensively looking for ambiguities and using extremely clear, consistent, and conscious language for all of the specifications, especially with regard to the MUST/SHOULD/MAY kinds of language and the existence of a complete authoritative ABNF grammar of which the text is really only an elucidation. If I'm right, getting CAP out the door could be a pyrrhic victory. If it were up to me -- and I've been nominated to join the IAB, for whatever that's worth -- I don't think I could support advancing CAP to proposed standard as it stands, but I'm notoriously picky and wouldn't have supported moving several of the other documents to that stage, either, had I been involved at the time. I want a lot more clarity and a lot less ambiguity, or we're going to start having proposed standards with incompatible implementations. In any event, even if my requirements are too demanding for "Proposed" status, I predict that my concerns will be major problems later in moving the documents to Draft and Full standard status. (For reference, it took us a long time to get MIME to Proposed status, but the process was *relatively* painless and mechanical from then on because there really weren't that many ambiguities left.) Given this perspective, there's an argument to be made that the logical thing to do is to "finish" the CAP document (for some careful definition of "finish") and then open a whole new round of revisions to the CALSCH documents, including CAP. I would be willing to serve as a document editor for such a round of revisions. But in the meantime, we have to either put CAP to bed or put it on hold for a whole new round. One of the reasons I've been lurking quietly is that I had hoped to postpone my more active involvement until CAP was finished, but I now think that putting our recent discussion in the context of the larger needs of CALSCH might actually help us figure out how to finish CAP. To put it in perspective: The CAP document describes an early stage protocol with no functionally interoperating implementations (that I know of). This means that it WILL have mistakes in it -- there's no substitute for building interoperable code for fleshing out those mistakes. So we don't have to believe that CAP is perfect for us to sign off on it, because we know that it will simply provide a basis for further experiments toward the goal of a fully interoperable protocol. Remembering that perfection is not a requirement should be helpful. Instead of perfection, I think we should be pursuing a somewhat more modest goal, which is to identify and correct any deficiencies in the current CAP spec that can be reasonably anticipated to cause major headaches for that next round of standardization efforts. It is my preference to confine my own comments on CAP to that category of problems that could significantly complicate the efforts that I am volunteering to help lead for the next round of CALSCH document revisions. Thus, with that ridiculous amount of prologue -- and with gratitude to anyone who has read this far -- I now offer my own opinions about what we need to fix to put this version of CAP to bed. There are three things that I regard as *potential* showstoppers, though not difficult ones to fix: Versioning: The CAP-VERSION property as currently defined is simply not adequate to allow us the possibility of gracefully introducing incompatible changes in future versions. As I contemplate an involvement in such future refinements, I can't imagine a more "showstopping" problem than this one. FWIW, I speak from bitter experience: for those of you who don't realize it, "MIME-Version" has an inadequate definition that almost certainly precludes *any* future values other than 1.0. I would like to see CAP avoid the same mistake, as I think the cost would be much greater for CAP than it was for MIME. CALSCALE -- I would like to either see us add a capability specification for calendar scales and a special error code for unsupported calendar scales, or I would like someone to convince me that the absence of such scales isn't really a problem for future extensions. What we have right now tells us that there might be other calendar scales, but doesn't really tell an implementation how to behave if it encounters one. ABNF -- There simply must be a complete ABNF for a standards-track protocol, in my opinion. However, I'm also not convinced that releasing CAP as an Experimental RFC without such an ABNF would in any way impede CAP's progress in the market. In fact, publication as an Experimental RFC might well be the smartest, fastest track for closure on the current document. I could support publication as an experimental RFC if only my first two issues (CAP-VERSION and handling of unrecognized CALSCALE values) are resolved. There are a couple of more things I would really like to see cleaned up, though I can imagine publication (especially as Experimental) without fixing them: "SCOPING" -- The issue discussed as "SCOPING" on the list concerns me, but only as an easily-clarified ambiguity. It seems that sometimes when you say "SELECT VALARM" (or SELECT whatever), you want only the VALARM (or whatever), and sometimes you want the whole enclosing ical body, including the time zone, product-id, method, cal-scale, the whole kit and kaboodle. I can understand -- barely -- why you might sometimes NOT want the enclosing stuff, but surely you often do want it, so either we need to be crystal clear that "everything" (properly defined) is to be returned, or we need to provide two forms of the request to get the two kinds of return. VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems to me that there are several ambiguities here. I think that we must be clear about a requirement that servers MUST provide "currently accurate" freebusy information in response to an appropriate request. And I'm definitely confused about why one would want to permit the use of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the ITIP syntax for requesting this information. Finally, there are a couple of things that I am still confused about after months on the list. This doesn't necessarily mean there's a problem, but it certainly makes me nervous -- at the risk of sounding arrogant, if I haven't figured it out yet, I'm not optimistic that all implementors will "figure it out" in a compatible way: EXPAND and QUERYID -- I am having a hard time understanding how stored queries can be useful without search wildcards. Can anyone explain this to me? Alarms/SEQUENCE -- I remain confused: Can there be two identical objects in the same calendar? If not, we should clearly say so. Anyway, I apologize for the length of this message and for its appearance at such a late pre-Minneapolis moment, but since Satya has honored me with the suggestion that I might be of help, I thought I should try to lay out my current thinking as clearly as possible. I look forward to seeing as many as possible of you in Minneapolis! -- Nathaniel --Apple-Mail-86--277814710-- From owner-ietf-calendar@mail.imc.org Fri Nov 7 12:44:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26345 for ; Fri, 7 Nov 2003 12:44:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7HLdkT045334 for ; Fri, 7 Nov 2003 09:21:39 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7HLc4r045333 for ietf-calendar-bks; Fri, 7 Nov 2003 09:21:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7HLbkT045327 for ; Fri, 7 Nov 2003 09:21:38 -0800 (PST) (envelope-from cjohnson@myrealbox.com) Received: from hp1 cjohnson@smtp-send.myrealbox.com [205.208.215.164] by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 3.44 $ on Novell NetWare; Fri, 07 Nov 2003 10:21:39 -0700 Message-ID: <002701c3a553$7cff4a80$0200000a@hp1> From: "Craig Johnson" To: Subject: Re: Auto reply and VFREEBUSY Date: Fri, 7 Nov 2003 10:20:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C3A518.D0230520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C3A518.D0230520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doug wrote > The new limitation of the auto reply CAP mode is that the > requester will not get the CU's blocked out time, but the > CALID's busy time. In iTIP/iMIP mode the requester can get the CU's > blocked out time as the CUA knows about other of the CU's > calendars. That is an interesting new distinction. > If we make everything always auto reply, then we can no longer > get the CU's blocked out time (When it differs from the one > specific calendar the requester connected to with CAP ). >=20 > Plus not all CS's can respond (reasons given in previous post). Keep in mind that waiting two hours or two days until each ATTENDEE = fires up their CUA and finally responds to the request renders free-busy = searches practically useless. It is pragmatically undesirable (a point = made in several previous threads.) It is worth noting that a substantial majority of 'Calendar Stores' = operating today, particularly in corporate environments, respond to = free-busy requests (iCAL standard or proprietary) without the = involvement of some 'ATTENDEE/CUA' equivalent. In other words, = auto-reply is the de facto mode of operation. Anything less in those = environments would be unacceptable. Nevertheless, some entity or application may wish to operate in the = "high latency" mode. I don't think anything proposed so far precludes = that. > I am suggesting that the 'auto' response (which is a new idea in CAP) > be done with CREATE/VFREEBUSY+REPLY. That's a move in the right direction, but I think we can do better. We = don't say SEARCH+REPLY, MOVE+REPLY, or MODIFY+REPLY because a REPLY is = inherent with the command. Why can't a free-busy reply also be inherent? I think breaking away from the CREATE command would, also, be = preferable. We could more simply use GET-FREEBUSY (a new command) or = overload the SEARCH command. The reply would be inherent, just like = other CAP commands. That makes much more sense. We would have the = following variations for VFREEBUSY requests: (The following should be in = mono-spaced font to display correctly. My apologies to recipients where = this doesn't happen.) iTIP/iMIP iTIP/CAP CAP BEGIN:VCALENDAR BEGIN:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 VERSION:2.0 VERSION:2.0 PRODID://somecalid PRODID://somecalid PRODID://somecalid CMD:CREATE CMD:GET-FREEBUSY or SEARCH METHOD:REQUEST METHOD:REQUEST =20 BEGIN:VFREEBUSY BEGIN:VFREEBUSY BEGIN:VFREEBUSY DTSTART:BegOfPeriod DTSTART:BegOfPeriod DTSTART:BegOfPeriod DTEND:EndOfPeriod DTEND:EndOfPeriod DTEND:EndOfPeriod ORGANIZER: ... ORGANIZER: ... ORGANIZER: ... ATTENDEE: ... ATTENDEE: ... ATTENDEE: ... UID: ... UID: ... UID: ... DTSTAMP: ... DTSTAMP: ... DTSTAMP: ... END:VFREEBUSY END:VFREEBUSY END:VFREEBUSY END:VCALENDAR END:VCALENDAR END:VCALENDAR Note that the "VFREEBUSY request" component is identical in all cases. = The VFREEBUSY defines a request for free-busy information. The CAP = version doesn't include a METHOD property because it would then be bound = by iTIP/CAP handling rules. "CMD:CREATE" wouldn't make sense because we = are not "creating" the accompanying VFREEBUSY component. CAP can = inherently reply directly to the request. > And that the CUA non-'auto' response be done as it is now with > iTIP/iMIP in the CUA (data stored in the CS) so that the > existing iTIP flow not be altered. > > Currently the iTIP/iMIP method gets you the CU's busy time as > determined by the CUA. If the CS is capable, it would be MUCH preferable (and useful) for the = CS to "auto-reply" to the iTIP/iMIP request. Some 'Calendar Stores' do = that already (ibid. the de facto behavior). A CS that isn't capable = could hold the request for the CUA to act on. >> Are you suggesting that a Calendar Store is not capable of=20 >> handling a VFREEBUSY request and providing a direct response? > >A VFREEBUSY/REQUEST is not auto respond to now and is not a real >time reply in 2445, 2446, or 2447. So why break CUA's that ADD the = users >blocked out time or merge multiple blocked out times from multiple >different calendars from working correctly? I don't think anything is broken. It will be the Calendar Store's = prerogative to "auto-reply" or "hold for CUA". Some Calendar Stores may = characteristically behave one way or the other. Perhaps some Calendar = Stores will allow a CU setting to determine the behavior on a per = calendar basis. >There has been no requirement that what the CUA sent matched 100% >to items any user can find in a named calendar. A simple example >could be that the CUA always adds in the company holiday schedule >calendar to the users busy time. I concur! and further... A "Calendar Store" is ALSO capable of injecting = other "busy" information into an "auto-reply" (e.g. work schedule, = holidays). I am very familiar with such Calendar Stores. Of course, = that extra information is outside the scope of CAP. Nonetheless, such = information is characteristic of some 'Calendar Stores' just as it may = be characteristic of a CUA. It is easily accommodated by VFREEBUSY = requests and responses. Given a time period (DTSTART and DTEND) a = Calendar Store can whip up a VFREEBUSY response containing busy times = for appointments (regular and recurring), holidays, work-schedule, the = works. >> CAP does not support this WG's established definition (standard) for >> requesting free-busy information using the VFREEBUSY component ... >> and provide a direct real-time response. (RFC 2445, p 58) > >RFC 2445 does not specify real time processing of VFREEBUSY >and the words 'real-time' are NOT in that section or any other >section of 2445, or 2447. And its usage in 2446 is not on point, >except for enabling CAP (unnamed) as the new real-time transport. >Real time is what CAP adds. Yup. I was careless in forming my statement. Let me move the reference = and rephrase: CAP does not support this WG's established definition (standard) for requesting free-busy information: using the "VFREEBUSY component" (RFC 2445, p 58) ... and provide a direct CAP real-time response. The key point: using a "VFREEBUSY component" to make the request as per = WG definition. CAP still hasn't got it. (But I hope were getting = closer.) >> This point was made in a previous discussion thread which, after >> some give-and-take, eventually concurred on the issue. We anticipated >> this would be included in CAP-12; but, for reasons unknown it was = left >> out. A proposed solution has been provided several times. > >Real time VFREEBUSY calculations and replies are in -12. >It was not missed or skipped. The section you are thinking of attempts to describe a = "VFREEBUSY/QUERY". That's not the same as a "VFREEBUSY request" (which = is still not in CAP). >Your proposal was incomplete and failed to take into account >several items (see my reply to your post). You indicated that you >would digest my reply and comment. And I hoped fill in the missing >conditions that you did not take into account in your proposal. Yes, I said I would respond. However, subsequently it was deemed that = your post (which detailed "how various CS types might derive free-busy = information") was secondary to the key issue of "how a CUA makes the = request". We'd like to keep the focus on that and not get sidetracked. = Once that's resolved its simpler to move on to the issues in your post.=20 That's also why in one of the proposals we had a statement to the = effect: "How a CS derives a free-busy response from its data is an issue = for the CS and not the CUA." The CUA should be able to issue a = "VFREEBUSY request" regardless of what the CS does internally to produce = a response (the CUA being capable, of course). >Given that the CUA is what puts data into a CS and the CUA is >what gets data out of a CS, the CUA can pick iTIP/iMIP >(CU busy time) mode or the new auto-responce CAP (CALID >busy time) mode . Perhaps some CSs will be 'configurable' by the CU/CUA to operate in = either mode (on a per calendar basis). >Again CAP does have real time VFREEBUSY replies which is new to CAP >and did not exist in 2445, 2446, or 2447, Again, the real-time VFREEBUSY you refer to is a "VFREEBUSY/QUERY", and = not a "VFREEBUSY request" (the WG defined method for requesting = free-busy information). There are differences. These differences were = discussed in a previous thread; and, actually, Doug and Bruce corrected = me and brought some of these to my attention... One specific point: A "VFREEBUSY request" has all the information needed = to formulate a valid "VFREEBUSY response": (Attendee, Organizer, UID, = DTStart, DTEnd). This is something "VFREEBUSY/QUERY" lacks. =20 Suppose we did a "VFREEBUSY/QUERY". The result might include multiple = 'booked' and 'generated' VFREEBUSY components. What UID would the = resulting VFREEBUSY component(s) have? Would they retain their own UID? = Would they each get a consistent UID? Where from? What about = organizer & attendee? Does each VFREEBUSY have its own? Does it have = either of them? These could be derived from the Session Identity and = Target and the QUERY could 'magically' plug these values into every = VFREEBUSY component produced by the QUERY. But that's unlike any other = SEARCH/QUERY operation in CAP. Nothing does that. It seems that a = VFREEBUSY/QUERY would require some special handling to produce "valid" = VFREEBUSY responses. (I hope not to see a "magic mode" that facilitates = this.) I don't think many have thoroughly reviewed the new section which = describes VFREEBUSY/QUERY issues and constraints. The section is new = with CAP-12 and hasn't had the scrutiny that other sections have had. = I'm not sure I've yet seen a "QUERY" statement that "does the trick" for = a free-busy search. Those that come close are somewhat complicated = ("booked" vs "unprocessed", etc.) I am not suggesting that "VFREEBUSY/QUERY" can never work and should be = abandoned. But it is clearly NOT the best choice for making "a request = for free-busy information" ... and it's not the mechanism the WG defined = in 2445 (and 2446). A "VFREEBUSY request" is very straightforward and = does not suffer the drawbacks and unresolved issues of a = VFREEBUSY/QUERY. C Johnson (BTW: Thanks for the interaction. I'm finding it useful.) ------=_NextPart_000_0024_01C3A518.D0230520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Doug wrote

> The new limitation of the auto reply CAP mode is that = the
>=20 requester will not get the CU's blocked out time, but the
> = CALID's busy=20 time. In iTIP/iMIP mode the requester can get the CU's
> blocked = out time=20 as the CUA knows about other of the CU's
> = calendars.
That is an interesting new=20 distinction.
 
> If we make everything always auto = reply, then=20 we can no longer
> get the CU's blocked out time (When it differs = from the=20 one
> specific calendar the requester connected to with CAP = ).
>=20
> Plus not all CS's can respond (reasons given in previous=20 post).
Keep in mind that waiting two hours or = two days=20 until each ATTENDEE fires up their CUA and finally responds to the=20 request renders free-busy searches practically useless. It is=20 pragmatically undesirable (a point made in several previous=20 threads.)
 
It is worth noting that a substantial = majority of=20 =91Calendar Stores=92 operating today, particularly in corporate = environments,=20 respond to free-busy requests (iCAL standard or proprietary) without the = involvement of some =91ATTENDEE/CUA=92 equivalent.  In other=20 words, auto-reply is the de facto mode of operation.  Anything = less in=20 those environments would be unacceptable.
 
Nevertheless, some entity or = application may=20 wish to operate in the "high latency" mode. I don=92t think anything = proposed so=20 far precludes that.
 
> I am suggesting that the 'auto' = response=20 (which is a new idea in CAP)
> be done with=20 CREATE/VFREEBUSY+REPLY.
That's a move in the right direction, = but I think=20 we can do better. We don=92t say SEARCH+REPLY, MOVE+REPLY, or = MODIFY+REPLY=20 because a REPLY is inherent with the command. Why can't a free-busy = reply also=20 be inherent?
 
I think breaking away from the CREATE = command=20 would, also, be preferable.  We could more simply use = GET-FREEBUSY (a=20 new command) or overload the SEARCH command. The reply would be = inherent,=20 just like other CAP commands. That makes much more sense.  We = would=20 have the following variations for VFREEBUSY requests: (The = following should=20 be in mono-spaced font to display correctly.  My apologies=20 to recipients where this doesn't happen.)
 
iTIP/iMIP         &= nbsp;  iTIP/CAP        =      CAP
 
BEGIN:VCALENDAR      BEGIN:VCALEND= AR      BEGIN:VCALENDAR
VERSION:2.0         = ; VERSION:2.0         &= nbsp;VERSION:2.0
PRODID://somecalid   PRODID://somecalid &nbs= p; PRODID://somecalid
          &nbs= p;          CMD:CREATE&= nbsp;          CMD:GET-= FREEBUSY=20 or SEARCH
METHOD:REQUEST       METHOD:R= EQUEST       
BEGIN:VFREEBUSY      BEGIN:VFREEBU= SY      BEGIN:VFREEBUSY
DTSTART:BegOfPeriod  DTSTART:BegOfPeriod  DT= START:BegOfPeriod
DTEND:EndOfPeriod    DTEND:EndOfPeriod =    DTEND:EndOfPeriod
ORGANIZER:=20 ...       ORGANIZER:=20 ...       ORGANIZER: ...
ATTENDEE:=20 ...        ATTENDEE:=20 ...        ATTENDEE: = ...
UID:=20 ...           &nbs= p; UID:=20 ...           &nbs= p; UID:=20 ...
DTSTAMP:=20 ...         DTSTAMP:=20 ...         DTSTAMP:=20 ...
END:VFREEBUSY        END= :VFREEBUSY        END:VFREEBUSY
END:VCALENDAR        END= :VCALENDAR        END:VCALENDAR
 
Note that the "VFREEBUSY request" component is = identical in=20 all cases.  The VFREEBUSY defines a request for free-busy=20 information.  The CAP version doesn't include a METHOD property=20 because it would then be bound by iTIP/CAP handling rules. =20 "CMD:CREATE" wouldn't make sense because we are not "creating" the=20 accompanying VFREEBUSY component.  CAP can inherently = reply=20 directly to the request.

> And that the CUA = non-'auto'=20 response be done as it is now with
> iTIP/iMIP in the CUA (data = stored in=20 the CS) so that the
> existing iTIP flow not be = altered.
>
>=20 Currently the iTIP/iMIP method gets you the CU's busy time as
> = determined=20 by the CUA.
If the CS is capable, it would be MUCH = preferable=20 (and useful) for the CS to "auto-reply" to the iTIP/iMIP request. =20 Some =91Calendar Stores=92 do that already (ibid. the de facto = behavior). =20 A CS that isn=92t capable could hold the request for the CUA to act=20 on.
 
>> Are you suggesting that a = Calendar Store=20 is not capable of
>> handling a VFREEBUSY request = and providing=20 a direct response?
>
>A VFREEBUSY/REQUEST is not auto = respond to now=20 and is not a real
>time reply in 2445, 2446, or 2447. So why break = CUA's=20 that ADD the users
>blocked out time or merge multiple blocked out = times=20 from multiple
>different calendars from working = correctly?
 
I don't think anything is broken. It = will be the=20 Calendar Store's prerogative to "auto-reply" or "hold for CUA".  = Some=20 Calendar Stores may characteristically behave one way or the = other. =20 Perhaps some Calendar Stores will allow a CU setting to = determine the=20 behavior on a per calendar basis.

>There has been no requirement that what the CUA sent = matched=20 100%
>to items any user can find in a named calendar. A simple=20 example
>could be that the CUA always adds in the company holiday=20 schedule
>calendar to the users busy time.
 
I concur! and further... A "Calendar = Store"=20 is ALSO capable of injecting other "busy" information into an=20 "auto-reply" (e.g. work schedule, holidays).  I am very familiar = with such=20 Calendar Stores.  Of course, that extra information is outside = the=20 scope of CAP.  Nonetheless, such information is characteristic of = some=20 =91Calendar Stores=92 just as it may be characteristic of a = CUA.  It=20 is easily accommodated by VFREEBUSY requests and responses. Given a = time=20 period (DTSTART and DTEND) a Calendar Store can whip up a VFREEBUSY = response=20 containing busy times for appointments (regular and recurring), = holidays,=20 work-schedule, the works.

>> CAP=20 does not support this WG's established definition (standard) = for
>>=20 requesting free-busy information using the VFREEBUSY component = ...
>>=20 and provide a direct real-time response. (RFC 2445, p = 58)
>
>RFC 2445 does not specify real time = processing=20 of VFREEBUSY
>and the words 'real-time' are NOT in that section or = any=20 other
>section of 2445, or 2447. And its usage in 2446 is not on=20 point,
>except for enabling CAP (unnamed) as the new real-time=20 transport.
>Real time is what CAP adds.
 
Yup. I was careless in forming my = statement. Let me=20 move the reference and rephrase:

CAP does not support this WG's = established=20 definition (standard) for
requesting free-busy information: = using the=20 "VFREEBUSY component"
(RFC 2445, p 58) ... and provide a = direct CAP=20 real-time response.
 
The key point: using a "VFREEBUSY = component" to=20 make the request as per WG definition.  CAP still hasn't got = it.  (But=20 I hope were getting closer.)

>> This=20 point was made in a previous discussion thread which, after
>> = some=20 give-and-take, eventually concurred on the issue. We = anticipated
>>=20 this would be included in CAP-12; but, for reasons unknown it was=20 left
>> out. A proposed solution has = been provided=20 several times.
>
>Real time VFREEBUSY calculations and = replies are=20 in -12.
>It was not missed or skipped.
 
The section you are thinking of = attempts to=20 describe a "VFREEBUSY/QUERY". That's not the same as a "VFREEBUSY = request"=20 (which is still not in CAP).

>Your proposal was incomplete and failed to take into=20 account
>several items (see my reply to your post). You indicated = that=20 you
>would digest my reply and comment. And I hoped fill in the=20 missing
>conditions that you did not take into account in your=20 proposal.
Yes, I said I would respond. =20 However, subsequently it was deemed that your post (which detailed = "how=20 various CS types might derive free-busy information") was secondary to = the key=20 issue of "how a CUA makes the request". We=92d like to keep the focus on = that and=20 not get sidetracked. Once that's resolved its simpler to move on=20 to the issues in your post.
 
That=92s also why in one of the = proposals we had=20 a statement to the effect: "How a CS derives a free-busy response from = its data=20 is an issue for the CS and not the CUA." The CUA should be = able to=20 issue a "VFREEBUSY request" regardless of what the CS does = internally=20 to produce a response (the CUA being capable, of = course).
 
>Given that the CUA is what puts = data into a CS=20 and the CUA is
>what gets data out of a CS, the CUA can pick=20 iTIP/iMIP
>(CU busy time) mode or the new auto-responce CAP=20 (CALID
>busy time) mode .
 
Perhaps some CSs will be = =91configurable=92 by the=20 CU/CUA to operate in either mode (on a per calendar = basis).

>Again CAP=20 does have real time VFREEBUSY replies which is new to CAP
>and did = not=20 exist in 2445, 2446, or 2447,
 
Again, the real-time VFREEBUSY you = refer to is a=20 "VFREEBUSY/QUERY", and not a "VFREEBUSY request" (the WG defined method = for=20 requesting free-busy information). There are differences. These = differences were=20 discussed in a previous thread; and, actually, Doug and Bruce corrected = me and=20 brought some of these to my attention...
 
One specific point: A "VFREEBUSY = request" has all=20 the information needed to formulate a valid "VFREEBUSY=20 response": (Attendee, Organizer, UID, DTStart, DTEnd). This is something = "VFREEBUSY/QUERY" lacks. 
 
Suppose we did a = "VFREEBUSY/QUERY".  The=20 result might include multiple 'booked' and 'generated' VFREEBUSY=20 components.  What UID would the resulting VFREEBUSY=20 component(s) have?  Would they retain = their own UID? =20 Would they each get a consistent UID?  Where from?  What about = organizer & attendee? Does each VFREEBUSY have its own?  Does = it have=20 either of them?  These could be derived from the Session = Identity=20 and Target and the QUERY could =91magically=92 plug these = values into=20 every VFREEBUSY component produced by the QUERY.  But that=92s = unlike any other SEARCH/QUERY operation in CAP.  Nothing does=20 that.  It seems that a VFREEBUSY/QUERY would require some = special=20 handling to produce "valid" VFREEBUSY responses.  (I hope not = to see a=20 "magic mode" that facilitates this.)
 
I don=92t think many have thoroughly = reviewed the=20 new section which describes VFREEBUSY/QUERY issues and=20 constraints. The section is new with CAP-12 and hasn=92t had the = scrutiny that=20 other sections have had.  I'm not sure I=92ve yet seen a = "QUERY"=20 statement that "does the trick" for a free-busy search. Those that come = close=20 are somewhat complicated ("booked" vs "unprocessed", etc.)
 
I am not suggesting that = "VFREEBUSY/QUERY" can=20 never work and should be abandoned.  But it is clearly NOT the = best=20 choice for making "a request for free-busy information" ... = and it=92s=20 not the mechanism the WG defined in 2445 (and 2446).  A = "VFREEBUSY=20 request" is very straightforward and does not suffer the = drawbacks and=20 unresolved issues of a VFREEBUSY/QUERY.
 
C Johnson
 
(BTW:  Thanks for the = interaction.  I'm=20 finding it useful.)
------=_NextPart_000_0024_01C3A518.D0230520-- From owner-ietf-calendar@mail.imc.org Fri Nov 7 15:47:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07091 for ; Fri, 7 Nov 2003 15:47:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KRSkT051744 for ; Fri, 7 Nov 2003 12:27:28 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7KRS4Q051743 for ietf-calendar-bks; Fri, 7 Nov 2003 12:27:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7KROkT051737 for ; Fri, 7 Nov 2003 12:27:25 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA7KRIXK010966 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Nov 2003 12:27:19 -0800 Message-ID: <3FAC0021.9020707@Royer.com> Date: Fri, 07 Nov 2003 13:27:13 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Auto reply and VFREEBUSY References: <002701c3a553$7cff4a80$0200000a@hp1> In-Reply-To: <002701c3a553$7cff4a80$0200000a@hp1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040602050702010900020505" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040602050702010900020505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Craig Johnson wrote: > Doug wrote > > > The new limitation of the auto reply CAP mode is that the > > requester will not get the CU's blocked out time, but the > > CALID's busy time. In iTIP/iMIP mode the requester can get the CU's > > blocked out time as the CUA knows about other of the CU's > > calendars. > > That is an interesting new distinction. That's what I have been trying to figure out how to say for a while :-) > Keep in mind that waiting two hours or two days until each ATTENDEE=20 > fires up their CUA and finally responds to the request renders=20 > free-busy searches practically useless. It is pragmatically=20 > undesirable (a point made in several previous threads.) In which case the CUA that contacts the CS would want to use the CALID=20 mode and not the CU mode. (or see below) > It is worth noting that a substantial majority of =91Calendar Stores=92= =20 > operating today, particularly in corporate environments, respond to=20 > free-busy requests (iCAL standard or proprietary) without the=20 > involvement of some =91ATTENDEE/CUA=92 equivalent. In other words,=20 > auto-reply is the de facto mode of operation. Anything less in those=20 > environments would be unacceptable. That may be true, however the opposite it true for web calendars. Where=20 often the user must publish a VFREEBUSY manually and its contents may be a superset of the th= e publicly available calendar. With web calendars the CU/CUA publishes their VFREEBUSY calendar so the requester does not have to wait. The requester just gets the CU's=20 'published' VFREEBUSY, no delay. Currently how you get that is somewhat random as CAP does not=20 yet exist. We could modify 10.12.1 to say something like: for CS that RECUR-EXPAND/TRUE: A CREATE/VFREEBUSY/PUBLISH may be stored on the CS by the owner to indicate CUs busy time. When the requester wishes the CU busy time SEARCH for VFREEBUSY/PUBLISH. When the requester wishes the CALID busy time SEARCH for VFREEBUSY/booked= =2E Then state that if a VFREEBUSY/PUBLISH is NOT in the CALID, then the CS=20 returns an automatically calculated VFREEBUSY/booked value. And tweak the RECUR-EXPAND/FALSE to match: A CREATE/VFREEBUSY/PUBLISH may be stored on the CS by the owner to indicate CUs busy time. When the requester wishes the CU busy time SEARCH for VFREEBUSY/PUBLISH. When the requester wishes the CALID busy time SEARCH for VFREEBUSY/booked= =2E Then state that if there is no VFREEBUSY/PUBLISH in the CALID, a successf= ul empty VFREEBUSY be returned. And as a RECUR-EXPAND/FALSE CS can not automatically generate VFREEBUSY booked items, then all requests will be treated as if they are a SEARCH VFREEBUSY/PUBLISH. > Nevertheless, some entity or application may wish to operate in the=20 > "high latency" mode. I don=92t think anything proposed so far precludes= =20 > that. The only way it would be precluded is if all searches for VFREEBUSY retur= n automatically calculated results. Which was one of the original proposals= =2E > > I am suggesting that the 'auto' response (which is a new idea in CAP)= > > be done with CREATE/VFREEBUSY+REPLY. > That's a move in the right direction, but I think we can do better. We = > don=92t say SEARCH+REPLY, MOVE+REPLY, or MODIFY+REPLY because a REPLY i= s=20 > inherent with the command. Why can't a free-busy reply also be inherent= ? > I think breaking away from the CREATE command would, also, be=20 > preferable. We could more simply use GET-FREEBUSY (a new command) or=20 > overload the SEARCH command. The reply would be inherent, just like=20 > other CAP commands. That makes much more sense. We would have the=20 > following variations for VFREEBUSY requests: (The following should be=20 > in mono-spaced font to display correctly. My apologies to recipients=20 > where this doesn't happen.) > iTIP/iMIP iTIP/CAP CAP > ....... > Note that the "VFREEBUSY request" component is identical in all cases. = > The VFREEBUSY defines a request for free-busy information. The CAP=20 > version doesn't include a METHOD property because it would then be=20 > bound by iTIP/CAP handling rules. "CMD:CREATE" wouldn't make sense=20 > because we are not "creating" the accompanying VFREEBUSY component.=20 > CAP can inherently reply directly to the request. Is that not already what "10.12.1 Searching for VFREEBUSY" does +/- some = minor tweaks? And some implementations currently allow the CU to PUBLISH their CU=20 VFREEBUSY on the calendar, so CREATE/METHOD:PUBLISH is valid. > > > And that the CUA non-'auto' response be done as it is now with > > iTIP/iMIP in the CUA (data stored in the CS) so that the > > existing iTIP flow not be altered. > > > > Currently the iTIP/iMIP method gets you the CU's busy time as > > determined by the CUA. > > If the CS is capable, it would be MUCH preferable (and useful) for the = > CS to "auto-reply" to the iTIP/iMIP request. Some =91Calendar Stores=92= do=20 > that already (ibid. the de facto behavior). A CS that isn=92t capable=20 > could hold the request for the CUA to act on. Yes. And only when that is the desired behavior of the requester, else=20 the requester could never ask for the CU busy time vs the CALID busy time. > >> Are you suggesting that a Calendar Store is not capable of > >> handling a VFREEBUSY request and providing a direct response? > > > >A VFREEBUSY/REQUEST is not auto respond to now and is not a real > >time reply in 2445, 2446, or 2447. So why break CUA's that ADD the use= rs > >blocked out time or merge multiple blocked out times from multiple > >different calendars from working correctly? > I don't think anything is broken. It will be the Calendar Store's=20 > prerogative to "auto-reply" or "hold for CUA". Some Calendar Stores=20 > may characteristically behave one way or the other. Perhaps some=20 > Calendar Stores will allow a CU setting to determine the behavior on a = > per calendar basis. Yes. It would only be broken if we only allowed auto-generate of the repl= y. > > >There has been no requirement that what the CUA sent matched 100% > >to items any user can find in a named calendar. A simple example > >could be that the CUA always adds in the company holiday schedule > >calendar to the users busy time. > I concur! and further... A "Calendar Store" is ALSO capable of=20 > injecting other "busy" information into an "auto-reply" (e.g. work=20 > schedule, holidays). I am very familiar with such Calendar Stores. Of=20 > course, that extra information is outside the scope of CAP.=20 > Nonetheless, such information is characteristic of some =91Calendar=20 > Stores=92 just as it may be characteristic of a CUA. It is easily=20 > accommodated by VFREEBUSY requests and responses. Given a time period=20 > (DTSTART and DTEND) a Calendar Store can whip up a VFREEBUSY response=20 > containing busy times for appointments (regular and recurring),=20 > holidays, work-schedule, the works. Yes. > Perhaps some CSs will be =91configurable=92 by the CU/CUA to operate in= =20 > either mode (on a per calendar basis). I do not have a problem with configurable, but we need to allow the=20 fetching of CU vs CALID as separate tasks that might return the same results. > > One specific point: A "VFREEBUSY request" has all the information=20 > needed to formulate a valid "VFREEBUSY response": (Attendee,=20 > Organizer, UID, DTStart, DTEnd). This is something "VFREEBUSY/QUERY"=20 > lacks. Maybe I am misunderstanding you, but a VFREEBUSY/REQUEST is prohibited from having ATTENDEE and UID (See iTIP page 32). And VFREEBUSY/QUERY does allow searching for any contents in a VFREEBUSY (unprocessed or booked, manually created or auto generated) which would=20 include the DTSTART and DTEND values. > Suppose we did a "VFREEBUSY/QUERY". The result might include multiple=20 > 'booked' and 'generated VFREEBUSY components. As written you would get the calculated results for BOOKED. > What UID would the resulting VFREEBUSY component(s) have? Who cares as you would need one per unique request, so why not just generate a new UID for each VFREEBUSY/REPLY? > Would they retain their own UID? If they are auto-generated, I would have a new UID for each reply. If not, they would contain what had been stored. > Would they each get a consistent UID? Where from? What about organizer = > & attendee? Per iTIP, the ATTENDEE in a VFREEBUSY/REPLY is the "address of the=20 recipient replying". And the ORGANIZER "MUST be the request originator's address" > Does each VFREEBUSY have its own? Does it have either of them? These=20 > could be derived from the Session Identity and Target and the QUERY=20 > could =91magically=92 plug these values into every VFREEBUSY component = > produced by the QUERY. But that=92s unlike any other SEARCH/QUERY=20 > operation in CAP. Nothing does that. It seems that a VFREEBUSY/QUERY=20 > would require some special handling to produce "valid" VFREEBUSY=20 > responses. (I hope not to see a "magic mode" that facilitates this.) Again, I feel that the VFREEBUSY/SEARCH be the auto generated one for the CALID. I think the WG wants auto generated VFREEBUSY/REPLY, so that does mean so= me kind of magic mode. > I don=92t think many have thoroughly reviewed the new section which=20 > describes VFREEBUSY/QUERY issues and constraints. The section is new=20 > with CAP-12 and hasn=92t had the scrutiny that other sections have had.= =20 > I'm not sure I=92ve yet seen a "QUERY" statement that "does the trick" = > for a free-busy search. Those that come close are somewhat complicated = > ("booked" vs "unprocessed", etc.) > I am not suggesting that "VFREEBUSY/QUERY" can never work and should=20 > be abandoned. But it is clearly NOT the best choice for making "a=20 > request for free-busy information" ... and it=92s not the mechanism the= =20 > WG defined in 2445 (and 2446). A "VFREEBUSY request" is very=20 > straightforward and does not suffer the drawbacks and unresolved=20 > issues of a VFREEBUSY/QUERY. My only strong feelings is that the iTIP/VFREEBUSY still be the CU=20 VFREEBUSY/REPLY as it currently is (even if it happens to be the same as the CALID=20 VFREEBUSY/REPLY). Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040602050702010900020505 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA3MjAyNzEzWjAjBgkqhkiG9w0BCQQxFgQUH04+tqDDhZgPZ+YlGdV2 p6iLybAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAkQYCaajijYV9X/A6G1pWc8HIzrcaCEI0zSfQVMNM+xXrlyZCPMt+67mYp8HVPbiG zicQExZbWxCRpzwdeW0Vl1HMnIWogqwaymOgHqTHISh8VdiDBafx28mvqQUl1/R6k6A7lXey TT4OAjQDy4fDPlrgU7YHKTWA08ilSqm4grFUfc9fHJXhuldvQMr90VwA1ILFwP94TBlBYkv1 2c6yczgSKVETNd5keyUtQ0DwEtqZGKDbICIQIfepqRwpunpaWy//XEGVplffLNH6TiNrsP9Y yQOgZwMoXTB3zcXDqWW4pY3+o8eyOsX7+15aZZsgHSDPxQ2pIeFIjcNTeyypMAAAAAAAAA== --------------ms040602050702010900020505-- From owner-ietf-calendar@mail.imc.org Fri Nov 7 16:28:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08534 for ; Fri, 7 Nov 2003 16:28:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7LEMkT053253 for ; Fri, 7 Nov 2003 13:14:22 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7LEMwq053252 for ietf-calendar-bks; Fri, 7 Nov 2003 13:14:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7LEHkT053247 for ; Fri, 7 Nov 2003 13:14:17 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA7LEGXK011686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Nov 2003 13:14:17 -0800 Message-ID: <3FAC0B23.7060504@Royer.com> Date: Fri, 07 Nov 2003 14:14:11 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group References: <306166D6-1142-11D8-A05D-000A9571873E@guppylake.com> In-Reply-To: <306166D6-1142-11D8-A05D-000A9571873E@guppylake.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090608020908010901030307" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090608020908010901030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the awesome feedback! Nathaniel Borenstein wrote: > On Tuesday, November 4, 2003, at 07:06 PM, Satya Vempati wrote: > > Would it be possible to get someone like Nathaniel Borenstein to > take the role of a co-editor (if he is interested)? It would help > to have a seasoned veteran of the IETF process to help move things > forward. > > .... > > > It is my opinion that ALL of the CALSCH documents -- not just CAP -- > need a lot of work. A successful standard needs to be completely free > of ambiguity. You don't get there simply by tending to the most > urgently yelled-about issues, you get there by comprehensively looking > for ambiguities and using extremely clear, consistent, and conscious > language for all of the specifications, especially with regard to the > MUST/SHOULD/MAY kinds of language and the existence of a complete > authoritative ABNF grammar of which the text is really only an > elucidation. Yes. I agree. > ... > > Given this perspective, there's an argument to be made that the > logical thing to do is to "finish" the CAP document (for some careful > definition of "finish") and then open a whole new round of revisions > to the CALSCH documents, including CAP. I would be willing to serve as > a document editor for such a round of revisions. But in the meantime, > we have to either put CAP to bed or put it on hold for a whole new > round. One of the reasons I've been lurking quietly is that I had > hoped to postpone my more active involvement until CAP was finished, > but I now think that putting our recent discussion in the context of > the larger needs of CALSCH might actually help us figure out how to > finish CAP. If CAP were to re-start (I would say not something to do), I think that the way to make progress would be to break it up into (off of the top of my head); general CMD/REPLY doc, each specific CMD doc, and allow them ALL to be transported via iTIP so that the transport (BEEP, TCP, HTTP, iMIP, or whatever) can be independent of the overall design. > .... > > Versioning: The CAP-VERSION property as currently defined is simply > not adequate to allow us the possibility of gracefully introducing > incompatible changes in future versions. As I contemplate an > involvement in such future refinements, I can't imagine a more > "showstopping" problem than this one. FWIW, I speak from bitter > experience: for those of you who don't realize it, "MIME-Version" has > an inadequate definition that almost certainly precludes *any* future > values other than 1.0. I would like to see CAP avoid the same mistake, > as I think the cost would be much greater for CAP than it was for MIME. Currently the iCAL 'VERSION' property of iCAL has the same problem as MIME-Version. However the CAP-VERSION is more ~like~ the telnet capability in that you can list the specific CAP-ish things. It is not a VERSION as much as a list of docs the CS (or CUA) supports. So I do not think it has the same problem as the MIME-Version and iCAL VERSION properties. If we were to change it to be like the iCAL VERSION property (as some have recently almost proposed) - then it would have the same problem as the MIME-Version issue. > > CALSCALE -- I would like to either see us add a capability > specification for calendar scales and a special error code for > unsupported calendar scales, or I would like someone to convince me > that the absence of such scales isn't really a problem for future > extensions. What we have right now tells us that there might be other > calendar scales, but doesn't really tell an implementation how to > behave if it encounters one. iCAL can do a 'REQUEST-STATUS:3.1;Invalid property value;CALSCALE:foo' now and seems the correct choice for an unknown CALSCALE. Until someone proposes a new CALSCALE I do not think we can pre-specify any behavior. Currently there is no way to specify in a request the desired CALSCALE. Easy to add, but not something that can break existing CUA's. We could add text that says something like 'if you get a CALSCALE that you can not handle in the CAPABILITY reply, drop the connection as you can not do anything anyway...' . However that is true of (and the point of) the CAPABILITY reply, to find out if you can interoperate. > > ABNF -- ... > > There are a couple of more things I would really like to see cleaned > up, though I can imagine publication (especially as Experimental) > without fixing them: > > "SCOPING" -- The issue discussed as "SCOPING" on the list concerns me, > but only as an easily-clarified ambiguity. It seems that sometimes > when you say "SELECT VALARM" (or SELECT whatever), you want only the > VALARM (or whatever), and sometimes you want the whole enclosing ical > body, including the time zone, product-id, method, cal-scale, the > whole kit and kaboodle. I can understand -- barely -- why you might > sometimes NOT want the enclosing stuff, but surely you often do want > it, so either we need to be crystal clear that "everything" (properly > defined) is to be returned, or we need to provide two forms of the > request to get the two kinds of return. Thanks for the succinct explanation. As no one has proposed any solutions, I'll see if I can send some ideas to the list to clarify the text. > > VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems > to me that there are several ambiguities here. I think that we must be > clear about a requirement that servers MUST provide "currently > accurate" freebusy information in response to an appropriate request. > And I'm definitely confused about why one would want to permit the use > of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the > ITIP syntax for requesting this information. Because some want and expect the CU (user) VFREEBUSY and others want the CALID (calendar) VFREEBUSY. Currently the iTIP method gets the CU VFREEBUSY that just might be the same as the CALID VFREEBUSY. > Finally, there are a couple of things that I am still confused about > after months on the list. This doesn't necessarily mean there's a > problem, but it certainly makes me nervous -- at the risk of sounding > arrogant, if I haven't figured it out yet, I'm not optimistic that all > implementors will "figure it out" in a compatible way: > > EXPAND and QUERYID -- I am having a hard time understanding how stored > queries can be useful without search wildcards. Can anyone explain > this to me? We dropped the ability to auto execute stored queries. There is NO restriction that the results of fetching a stored query return static results (the same is true for all components) . So I could define (using unspecified admin tools) a stored query called 'TODAY' that returns a dynamically returns a VQUERY when run returns the results of todays events from several calendars. When we had auto-execute, then you could run them without fetching them. Now you have to fetch them and then run them (I still do not see why that is better). All of my requests for such an explanation have been ignored by those that do not want the CS to be able to have builtin, stored, or dynamically created queries. PDAs and devices on low bandwidth or high latency connections need this feature. > Alarms/SEQUENCE -- I remain confused: Can there be two identical > objects in the same calendar? If not, we should clearly say so. You can and iCAL has no such restriction on any component including VALARMs. Currently all components have a unique identifier within their context of usage. Some want no unique identifier, and their stated reasons specifically ignores the identical components issue. > Anyway, I apologize for the length of this message and for its > appearance at such a late pre-Minneapolis moment, but since Satya has > honored me with the suggestion that I might be of help, I thought I > should try to lay out my current thinking as clearly as possible. I > look forward to seeing as many as possible of you in Minneapolis! -- > Nathaniel I wish I could make it, I had planned on it, too much work,.. I'll be on Jabber. Thanks again for your succinct questions. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090608020908010901030307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA3MjExNDExWjAjBgkqhkiG9w0BCQQxFgQUJT3vT27LkaGhmEY9+dPN LypYjW4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAeQ/rRqGQw3jXts35Kl0EhartA2MJf8f27p1OwHGYFj3zqQe4NU37oKFOlzm5vL8/ g10FwqAD7+eW6UTX56gdHJ46gFjQfuUWPDpBt+KqRcoaLYoGJ1AHp5w4zncjNRvTMnIRbYO6 CwNN/dbGZ302O1l7zvSFmHxWPoYW/KuHmAgs76oGXRvYBOEhasvH19DNdrKBAJo8B1bL4keM 5U9YkEjM5LTVjIcof+LVcZUBNUn0bI9L8aFnVVRhonj2ZqiRSwRis82Ac8JRccKD8k4sLcrI afF5OTVgQM0FkLaVKXuZH/ISSug+eHhjOc5pJDRaupij+rEJgbp43jIMfHGRWQAAAAAAAA== --------------ms090608020908010901030307-- From owner-ietf-calendar@mail.imc.org Fri Nov 7 16:46:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09360 for ; Fri, 7 Nov 2003 16:46:32 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7LXbkT053896 for ; Fri, 7 Nov 2003 13:33:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA7LXbLO053895 for ietf-calendar-bks; Fri, 7 Nov 2003 13:33:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA7LXYkT053888 for ; Fri, 7 Nov 2003 13:33:35 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003110716475616570 for ; Fri, 07 Nov 2003 16:47:56 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 7 Nov 2003 16:30:39 -0500 Message-ID: <3FAC0EFF.6060000@centive.com> Date: Fri, 07 Nov 2003 16:30:39 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group References: <306166D6-1142-11D8-A05D-000A9571873E@guppylake.com> <3FAC0B23.7060504@Royer.com> In-Reply-To: <3FAC0B23.7060504@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2003 21:30:39.0730 (UTC) FILETIME=[63E6CD20:01C3A576] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >> EXPAND and QUERYID -- I am having a hard time understanding how >> stored queries can be useful without search wildcards. Can anyone >> explain this to me? We dropped the ability to auto execute stored >> queries. > > > There is NO restriction that the results of fetching a stored query > return static results (the > same is true for all components) . So I could define (using > unspecified admin tools) a stored > query called 'TODAY' that returns a dynamically returns a VQUERY when > run returns the results of todays events from several calendars. It basically democratizes the process of developing noninteroperable extensions: if your CS has these unspecified tools, then any admin can add new verbs to the protocol, and a CUA has to hope that the user knows what the stored query's name means. -- /===============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===============================================================| |Any sufficiently rigged demo is indistinguishable from advanced| |technology. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 7 19:29:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16170 for ; Fri, 7 Nov 2003 19:29:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA80ITkT058426 for ; Fri, 7 Nov 2003 16:18:29 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA80ITgN058425 for ietf-calendar-bks; Fri, 7 Nov 2003 16:18:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA80ISkT058420 for ; Fri, 7 Nov 2003 16:18:28 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA80IPXK013802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Nov 2003 16:18:27 -0800 Message-ID: <3FAC364C.7030007@Royer.com> Date: Fri, 07 Nov 2003 17:18:20 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group References: <306166D6-1142-11D8-A05D-000A9571873E@guppylake.com> <3FAC0B23.7060504@Royer.com> <3FAC0EFF.6060000@centive.com> In-Reply-To: <3FAC0EFF.6060000@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000000010009050703020301" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000000010009050703020301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > It basically democratizes the process of developing noninteroperable > extensions: if your CS has these unspecified tools, then any admin can > add new verbs to the protocol, and a CUA has to hope that the user > knows what the stored query's name means. By admin I did not mean that the user is not the admin of their own calendar. I just meant non-cap unspecified tool, much like we allow for a non-cap unspecified tool to create immutable vcars. And by your same logic a non-owner admin could change all of the VEVENT UID's in your calendar breaking you -- and just as unlikely. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000000010009050703020301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA4MDAxODIwWjAjBgkqhkiG9w0BCQQxFgQUBYMUg49nU4iOU8BEHHr6 Lq7jw0gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAjYP8DbcCE+HSGDnTdyNFxz/2HqwIEs5OEW8NmVQttd2cA8p1Prt037I1uvj0dALe ZT9aCRA7cxzQJbcoQqbLGsskQvdm5j72GLZ0/vzUv5bUuCLYOoX59x3YKJSQ/VcSCm+PWwr5 wrgdNMoP0rb43nbvW+3bs2n72+Vz6LG0k1wrS12Y+mSvKiGsR/C5bSt2CJpeRvNqf5RPtN26 duiNHZ9jz+0H6FAXpX5GhRBlcVRGYCCI6ClA95WEoxg4EeJ9r3pahOY4QIDbpNQpsXsup4s2 vjGK83xxLSK4bucQ9bHQxR7VRw1IAzLA8Tajr+z3k7V/H04KypKYah63DcNGmwAAAAAAAA== --------------ms000000010009050703020301-- From owner-ietf-calendar@mail.imc.org Fri Nov 7 20:38:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18128 for ; Fri, 7 Nov 2003 20:38:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA81QQkT060559 for ; Fri, 7 Nov 2003 17:26:26 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA81QQnt060558 for ietf-calendar-bks; Fri, 7 Nov 2003 17:26:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from trout.cpsr.org (trout.cpsr.org [66.180.229.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA81QOkT060552 for ; Fri, 7 Nov 2003 17:26:25 -0800 (PST) (envelope-from nsb@guppylake.com) Received: from guppylake.com (trout [66.180.229.5]) by trout.cpsr.org (8.12.8p2/8.12.8) with ESMTP id hA81QQta092309 for ; Fri, 7 Nov 2003 17:26:27 -0800 (PST) (envelope-from nsb@guppylake.com) Date: Fri, 7 Nov 2003 20:27:34 -0500 Subject: CAP-VERSION (was Re: Status of the CALSCH working group) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Nathaniel Borenstein To: "ietf-calendar@imc.org" Content-Transfer-Encoding: 7bit In-Reply-To: <3FAC0B23.7060504@Royer.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, November 7, 2003, at 04:14 PM, Doug Royer wrote: > Currently the iCAL 'VERSION' property of iCAL has the same problem as > MIME-Version. > > However the CAP-VERSION is more ~like~ the telnet capability in that > you can list the specific > CAP-ish things. It is not a VERSION as much as a list of docs the CS > (or CUA) supports. > > So I do not think it has the same problem as the MIME-Version and iCAL > VERSION properties. > If we were to change it to be like the iCAL VERSION property (as some > have recently > almost proposed) - then it would have the same problem as the > MIME-Version issue. I remain confused as to the purpose of CAP-VERSION, and will take the liberty of asking a dumb question or two. First, as far as I can tell, the only example of its use is in a CUA's response to a GET-CAPABILITY command issued by a CS. Is there any other scenario where it is used? If so, what is it? If not, how does a CUA find out what CAP-VERSION is supported by the CS? How do the values for CAP-Version relate to the ical Version? Moreover, what does it mean for a CUA to say that it supports multiple CAP-VERSION values? For example, if in the fullness of time we have defined cap-versions "1.0" and "2.0", is it reasonable to imagine that a CUA returns CAP-VERSION: 1.0; 2.0 (alpha); 2.0 (beta) In this case, first please pardon my semicolon -- although Doug referred to CAP-VERSION as multivalued, I couldn't find any indication of what the separator should be so I made that up. Second, does this mean that the CUA is prepared to take data in a form labelled simply "2.0" or not? What if 1.0 and 2.0 actually have incompatible semantics for identical syntax -- how is the CUA supposed to know what it is seeing? Finally, why are we using version numbers like 1.0 -- is there an intended implication about how an implementation should handle unrecognized version numbers, such as "ignore minor version differences but insist on major version compatibility"? If so, we should spell it out, and if not, we should dispense with the frivolity of using "1.0" when "1" would carry no less information. I'm sure some of these are stupid questions, but I suspect at least some of them are meaningful. I know that it would be nice if I now made a proposal for how things *should* work, but I'm reluctant to do so before I understand the purpose of CAP-VERSION. Here are several possible purposes: -- Allowing the CUA to find out what version of the CAP protocol the CS supports. -- Allowing the CS to find out what version of the CAP protocol the CUA supports. -- Allowing the CUA to find out what iCal "Version" fields the CS supports. -- Allowing the CS to find out what iCal "Version" fields the CUA supports. Even if I did understand the purpose of CAP-VERSION, I'd still want to be sure that there's a way to tell which of the supported CAP-VERSIONs is actually being used. If I tell you I support 1.0 and 2.0, and you come back at me with a verb that has different meanings in the two versions, how do I know which you're using? This is the kind of stuff I most want to see us fix before we declare the document finished, because getting this wrong will make it much harder to fix anything else later. One of the reasons that MIME-Version didn't turn out to be a major problem is that document formats are relatively stable and rarely require negotiation. Information exchange protocols, however, often involve version negotiation, so the costs of screwing this up could be significant. -- Nathaniel From owner-ietf-calendar@mail.imc.org Fri Nov 7 21:05:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18729 for ; Fri, 7 Nov 2003 21:05:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA81rbkT061139 for ; Fri, 7 Nov 2003 17:53:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA81rbUr061138 for ietf-calendar-bks; Fri, 7 Nov 2003 17:53:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from trout.cpsr.org (trout.cpsr.org [66.180.229.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA81rakT061133 for ; Fri, 7 Nov 2003 17:53:36 -0800 (PST) (envelope-from nsb@guppylake.com) Received: from guppylake.com (trout [66.180.229.5]) by trout.cpsr.org (8.12.8p2/8.12.8) with ESMTP id hA81rbta092599; Fri, 7 Nov 2003 17:53:38 -0800 (PST) (envelope-from nsb@guppylake.com) Date: Fri, 7 Nov 2003 20:54:45 -0500 Subject: Re: How to define a CALSCALE? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-calendar@imc.org To: Matthias Laabs From: Nathaniel Borenstein In-Reply-To: <200311051633.27562.matthias.laabs@web.de> Message-Id: <8728A33C-118E-11D8-A05D-000A9571873E@guppylake.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think this would be a very illuminating enterprise. Although we shouldn't need to delay CAP for it as long as we resolve the CAP-VERSION ambiguities, I think it would be very good if several people were beginning to think about how to define new CALSCALEs. There are lots of fun issues. For example, the Hebrew calendar includes the delightful concept of a leap month which is *not* the last month of the year. Makes you want to be careful with using numeric values for years, doesn't it? -- Nathaniel On Wednesday, November 5, 2003, at 10:33 AM, Matthias Laabs wrote: > > Hi, > > I am interested in writing a CALSCALE for JALALI(persian) calendar. > Where can > I find information on how to write or where to propose it. Is the > Gregorian > CALSCALE defined somewhere? > > Thanks in advance, > > Matthias > > > From owner-ietf-calendar@mail.imc.org Fri Nov 7 21:06:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18760 for ; Fri, 7 Nov 2003 21:06:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA81u5kT061188 for ; Fri, 7 Nov 2003 17:56:05 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA81u4Jd061187 for ietf-calendar-bks; Fri, 7 Nov 2003 17:56:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from trout.cpsr.org (trout.cpsr.org [66.180.229.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA81u3kT061182 for ; Fri, 7 Nov 2003 17:56:03 -0800 (PST) (envelope-from nsb@guppylake.com) Received: from guppylake.com (trout [66.180.229.5]) by trout.cpsr.org (8.12.8p2/8.12.8) with ESMTP id hA81u6ta092674 for ; Fri, 7 Nov 2003 17:56:06 -0800 (PST) (envelope-from nsb@guppylake.com) Date: Fri, 7 Nov 2003 20:57:13 -0500 Subject: Alarms/SEQUENCE (was Re: Status of the CALSCH working group) Content-Type: multipart/alternative; boundary=Apple-Mail-120--244879600 Mime-Version: 1.0 (Apple Message framework v552) From: Nathaniel Borenstein To: "ietf-calendar@imc.org" In-Reply-To: <3FAC0B23.7060504@Royer.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-120--244879600 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Friday, November 7, 2003, at 04:14 PM, Doug Royer wrote: >> Alarms/SEQUENCE -- I remain confused: Can there be two identical >> objects in the same calendar? If not, we should clearly say so. > > You can and iCAL has no such restriction on any component including > VALARMs. > Currently all components have a unique identifier within their context > of usage. > Some want no unique identifier, and their stated reasons specifically > ignores the > identical components issue. But what does this mean? If you store two identical items in your database without any unique identifiers, how can a client ever choose one over the other? I'm having a hard time seeing how this is a good idea. -- Nathaniel --Apple-Mail-120--244879600 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Friday, November 7, 2003, at 04:14 PM, Doug Royer wrote: Alarms/SEQUENCE -- I remain confused: Can there be two identical objects in the same calendar? If not, we should clearly say so. You can and iCAL has no such restriction on any component including VALARMs. Currently all components have a unique identifier within their context of usage. Some want no unique identifier, and their stated reasons specifically ignores the identical components issue. But what does this mean? If you store two identical items in your database without any unique identifiers, how can a client ever choose one over the other? I'm having a hard time seeing how this is a good idea. -- Nathaniel --Apple-Mail-120--244879600-- From owner-ietf-calendar@mail.imc.org Sat Nov 8 00:43:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23636 for ; Sat, 8 Nov 2003 00:43:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA85V7kT067325 for ; Fri, 7 Nov 2003 21:31:07 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA85V7xo067324 for ietf-calendar-bks; Fri, 7 Nov 2003 21:31:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA85V5kT067316 for ; Fri, 7 Nov 2003 21:31:06 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com ([12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA85V5XK017291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Nov 2003 21:31:07 -0800 Message-ID: <3FAC7F86.7030806@Royer.com> Date: Fri, 07 Nov 2003 22:30:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alarms/SEQUENCE (was Re: Status of the CALSCH working group) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070301090305000004000200" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070301090305000004000200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nathaniel Borenstein wrote: > On Friday, November 7, 2003, at 04:14 PM, Doug Royer wrote: > > Alarms/SEQUENCE -- I remain confused: Can there be two > identical objects in the same calendar? If not, we should > clearly say so. > > > You can and iCAL has no such restriction on any component > including VALARMs. > Currently all components have a unique identifier within their > context of usage. > Some want no unique identifier, and their stated reasons > specifically ignores the > identical components issue. > > > But what does this mean? If you store two identical items in your > database without any unique identifiers, how can a client ever choose > one over the other? I'm having a hard time seeing how this is a good > idea. -- Nathaniel > I agree, they need unique id's. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070301090305000004000200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA4MDUzMDQ2WjAjBgkqhkiG9w0BCQQxFgQUsuMqD862MwaGs+2sRMR3 7crsPhMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEANmXYchUiugPDLa/EinOSh8KVN6q/hGLxLsM2fogGE99NPA2d/cuttOgBiHArjmXk IVcKOhHj8B2PghkaUnHajoX2mJ+okN6tPVOUKdKYkfO6rqjouJvxStcBbNZgcYeXvp5+SBbg PWO1nwrqJVJwvg1zpe/3DIlgtv+r7oryPesULnTHzI5jIJ/30voBUdn+PAIqZqqo6e2YRvrO 5kNxxEVh0K+rQrtRli6BLedfwF0//ee3tYnJLkLT5Guf6O5/M74fvYyM+OJA+0jAjYkI3NML nE3nv4nwKeE0NfoBA7yAES8mlZAOkIxy+fwMNBqR4iQxpb8IjAneVaujuWmC2wAAAAAAAA== --------------ms070301090305000004000200-- From owner-ietf-calendar@mail.imc.org Sat Nov 8 00:45:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23684 for ; Sat, 8 Nov 2003 00:45:41 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA85SJkT067273 for ; Fri, 7 Nov 2003 21:28:19 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA85SJHt067272 for ietf-calendar-bks; Fri, 7 Nov 2003 21:28:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA85SHkT067267 for ; Fri, 7 Nov 2003 21:28:18 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com ([12.110.12.238]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hA85SFXK017256 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 7 Nov 2003 21:28:16 -0800 Message-ID: <3FAC7EDA.5030407@Royer.com> Date: Fri, 07 Nov 2003 22:27:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-VERSION (was Re: Status of the CALSCH working group) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060408070604090801020407" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060408070604090801020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nathaniel Borenstein wrote: > On Friday, November 7, 2003, at 04:14 PM, Doug Royer wrote: > >> Currently the iCAL 'VERSION' property of iCAL has the same problem as >> MIME-Version. >> >> However the CAP-VERSION is more ~like~ the telnet capability in that >> you can list the specific >> CAP-ish things. It is not a VERSION as much as a list of docs the CS >> (or CUA) supports. >> >> So I do not think it has the same problem as the MIME-Version and >> iCAL VERSION properties. >> If we were to change it to be like the iCAL VERSION property (as some >> have recently >> almost proposed) - then it would have the same problem as the >> MIME-Version issue. > > > I remain confused as to the purpose of CAP-VERSION, and will take the > liberty of asking a dumb question or two. > > First, as far as I can tell, the only example of its use is in a CUA's > response to a GET-CAPABILITY command issued by a CS. Is there any > other scenario where it is used? Correct, that is the only time it is used. > If so, what is it? If not, how does a CUA find out what CAP-VERSION > is supported by the CS? How do the values for CAP-Version relate to > the ical Version? They do not relate to the iCal VERSION directly. It just happens that CAP uses iCal file format '2.0' (iCAL VERSION). > Moreover, what does it mean for a CUA to say that it supports multiple > CAP-VERSION values? For example, if in the fullness of time we have > defined cap-versions "1.0" and "2.0", is it reasonable to imagine that > a CUA returns > > CAP-VERSION: 1.0; 2.0 (alpha); 2.0 (beta) > > In this case, first please pardon my semicolon -- although Doug > referred to CAP-VERSION as multivalued, iCAL VERSION 2.0 separates multivalued property text items with a COMMA. See RFC 2445. > I couldn't find any indication of what the separator should be so I > made that up. Second, does this mean that the CUA is prepared to take > data in a form labelled simply "2.0" or not? What if 1.0 and 2.0 > actually have incompatible semantics for identical syntax -- how is > the CUA supposed to know what it is seeing? Per cap the value(s) is(are) the RFC number of the CAP protocol that the endpoint that sent the reply supports. If CS advertised incompatible versions of something then it would be hosing itself. > -- Allowing the CUA to find out what version of the CAP protocol the > CS supports. Look at the values the CS sends to the CUA in the CAP-VERSION property in the GET-CAPABILITY reply. > -- Allowing the CS to find out what version of the CAP protocol the > CUA supports. Look at the values the CUA sends to the CS in the CAP-VERSION property in the GET-CAPABILITY reply. Each end sends a GET-CAPABILITY to the other endpoint and gets back a set of properties (with values). > -- Allowing the CUA to find out what iCal "Version" fields the CS > supports. > -- Allowing the CS to find out what iCal "Version" fields the CUA > supports. So far only iCAL version 2.0 exists and RFC's 2446, 2447, and CAP specify iCAL as in 2445 (which means 2.0). If CAP-other-version were to come out, it would need to specify the iCAL version. Plus the iCal objects themselves are tagged with the iCAL VERSION. > Even if I did understand the purpose of CAP-VERSION, I'd still want to > be sure that there's a way to tell which of the supported CAP-VERSIONs > is actually being used. If I tell you I support 1.0 and 2.0, and you > come back at me with a verb that has different meanings in the two > versions, how do I know which you're using? Given: CAP-VERSION:1234,5678 Then it means the sending endpoint supports CAP as defined in RFC-1234 and RFC-5678 > This is the kind of stuff I most want to see us fix before we declare > the document finished, because getting this wrong will make it much > harder to fix anything else later. One of the reasons that > MIME-Version didn't turn out to be a major problem is that document > formats are relatively stable and rarely require negotiation. > Information exchange protocols, however, often involve version > negotiation, so the costs of screwing this up could be significant. > -- Nathaniel -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060408070604090801020407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTA4MDUyNzU0WjAjBgkqhkiG9w0BCQQxFgQUf1TwtDg9cKD1BVx6W4AA gc8xfDEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAM3rUf7TfBqCfMWPU+0WwiockkfnnH6ROY8gJelsQ2UAb8bUY20CCrK49zeYPxFuI TN+1OhvIyAk7ZHCaTmGDLMUKo/NreIOC68pqCJNPu6YCSrRMmixjkyZiOD/7QFkb13OIy0gj r4yguUSlGcFEA134/DLHfgVILTjaEzArkuqSr3ufVXSVWe5eGxaJlJnnEzQWMgd5avh331/B tNoErBcifvmUIjaHdy2yp2DgBN72kbiUAnJi/T2Rx2+E7XN3S/glpHj9cTEnxpuFjrrE34K6 IVi+ckEtjgIKw6/KkbwrpKmwM837MlSyQFaCIwYh/qFZiWICGtgmnwB0qXUyfQAAAAAAAA== --------------ms060408070604090801020407-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 10:19:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24106 for ; Mon, 10 Nov 2003 10:19:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAEs1kT075887 for ; Mon, 10 Nov 2003 06:54:01 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAEs1w2075886 for ietf-calendar-bks; Mon, 10 Nov 2003 06:54:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAEs0kT075881 for ; Mon, 10 Nov 2003 06:54:00 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAC0B23.7060504@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (Versioning) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 09:53:57 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 09:53:47 AM, Serialize complete at 11/10/2003 09:53:47 AM Content-Type: multipart/alternative; boundary="=_alternative 0051644785256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0051644785256DDA_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/07/2003 04:14:11 PM: > > Versioning: The CAP-VERSION property as currently defined is simply > > not adequate to allow us the possibility of gracefully introducing > > incompatible changes in future versions. As I contemplate an > > involvement in such future refinements, I can't imagine a more > > "showstopping" problem than this one. FWIW, I speak from bitter > > experience: for those of you who don't realize it, "MIME-Version" has > > an inadequate definition that almost certainly precludes *any* future > > values other than 1.0. I would like to see CAP avoid the same mistake, > > as I think the cost would be much greater for CAP than it was for MIME. > > Currently the iCAL 'VERSION' property of iCAL has the same problem as > MIME-Version. I dont recall seeing any previous WG postings regarding problems with iCalendars versioning design. In any case the topic is CAPs CAP-VERSION and its current design. > However the CAP-VERSION is more ~like~ the telnet capability in that > you can list the specific > CAP-ish things. It is not a VERSION as much as a list of docs the CS (or > CUA) supports. CAP defines CAP-VERSION as: Purpose: This property specifies the version of CAP supported. and iCalendar defined VERSION as: Purpose: This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. Unfortunately CAP does not say much more on the topic of using versions which means there is no clearly defined behaviour or expectations for CAP 1.0 implementations to follow in a consistant manner. Currently it is not a list of supported versions of CAP, it is a single valued property with no clearly defined behaviour for going forward. The issue of the "1.0" (pre-July 2003) vs "XXXX" RFC number (~July 2003) value change is secondary to the funcational questions of it. > So I do not think it has the same problem as the MIME-Version and iCAL > VERSION properties. The problem is compound: 1: The property is currently single valued, not multivalued. 2: The property has no clear definition of dealing with multiple values (ie: what is the expected or recommended behaviour if multiple values are found). 3: Is there any priority assumed by the ordering of multiple values. 4: If there is a disjoin between each sides supported version, what then? I think I had one other but thats enough to get some discussion going (I hope). iCalendars VERSION does not share these problems nor is it relevant to this CAP discussion. > If we were to change it to be like the iCAL VERSION property (as some > have recently > almost proposed) - then it would have the same problem as the > MIME-Version issue. You misread/misunderstood the 1st question on that topic that I asked even after I rephrased it. Please go reread it and see if its clearer... (The point about "numeric" formatting was due to the previous CAP versions using "1.0" vs the apparently undiscussed recent change to "XXXX", NOT a proposal of any kind.) 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 0051644785256DDA_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/07/2003 04:14:11 PM:
> > Versioning: The CAP-VERSION property as currently defined is simply
> > not adequate to allow us the possibility of gracefully introducing
> > incompatible changes in future versions. As I contemplate an
> > involvement in such future refinements, I can't imagine a more
> > "showstopping" problem than this one. FWIW, I speak from bitter
> > experience: for those of you who don't realize it, "MIME-Version" has
> > an inadequate definition that almost certainly precludes *any* future
> > values other than 1.0. I would like to see CAP avoid the same mistake,
> > as I think the cost would be much greater for CAP than it was for MIME.
>
> Currently the iCAL 'VERSION' property of iCAL has the same problem as
> MIME-Version.
I dont recall seeing any previous WG postings regarding problems with iCalendars versioning design.  In any case the topic is CAPs CAP-VERSION and its current design.

> However the  CAP-VERSION is more ~like~ the telnet capability in that
> you can list the specific
> CAP-ish things. It is not a VERSION as much as a list of docs the CS (or
> CUA) supports.
CAP defines CAP-VERSION as:

   Purpose: This property specifies the version of CAP supported.
and iCalendar defined VERSION as:

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

Unfortunately CAP does not say much more on the topic of using versions which means there is no clearly defined behaviour or expectations for CAP 1.0 implementations to follow in a consistant manner.

Currently it is not a list of supported versions of CAP, it is a single valued property with no clearly defined behaviour for going forward.  The issue of the "1.0" (pre-July 2003) vs "XXXX" RFC number (~July 2003) value change is secondary to the funcational questions of it.

> So I do not think it has the same problem as the MIME-Version and iCAL
> VERSION properties.
The problem is compound:

1: The property is currently single valued, not multivalued.
2: The property has no clear definition of dealing with multiple values (ie: what is the expected or recommended behaviour if multiple values are found).
3: Is there any priority assumed by the ordering of multiple values.
4: If there is a disjoin between each sides supported version, what then?

I think I had one other but thats enough to get some discussion going (I hope).

iCalendars VERSION does not share these problems nor is it relevant to this CAP discussion.

> If we were to change it to be like the iCAL VERSION property (as some
> have recently
> almost proposed) - then it would have the same problem as the
> MIME-Version issue.
You misread/misunderstood the 1st question on that topic that I asked even after I rephrased it.  Please go reread it and see if its clearer...  (The point about "numeric" formatting was due to the previous CAP versions using "1.0" vs the apparently undiscussed recent change to "XXXX", NOT a proposal of any kind.)

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 0051644785256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 10:30:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24489 for ; Mon, 10 Nov 2003 10:30:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAFGIkT077478 for ; Mon, 10 Nov 2003 07:16:18 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAFGIDu077477 for ietf-calendar-bks; Mon, 10 Nov 2003 07:16:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAFGHkT077472 for ; Mon, 10 Nov 2003 07:16:17 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12-e: Changing REQUEST-STATUS MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 10:12:40 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 10:16:04 AM, Serialize complete at 11/10/2003 10:16:04 AM Content-Type: multipart/alternative; boundary="=_alternative 00531AEB85256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00531AEB85256DDA_= Content-Type: text/plain; charset="US-ASCII" In looking up something related to CALSCALE I noticed that CAP-12-e makes an unmentioned change to iCalendars REQUEST-STATUS property. This change is NOT good NOR is it necessary. iCalendar defines REQUEST-STATUS as: Format Definition: The property is defined by the following notation: rstatus = "REQUEST-STATUS" rstatparam ":" statcode ";" statdesc [";" extdata] CAP-12-e proposes changing it to: rstatus = "REQUEST-STATUS" rstatparam ":" statcode ";" *(statdesc ) ";" *(extdata) This makes statdesc optional now PLUS it makes statdesc and extdata both multi valued. This is a non-backwards compatible change for no apparent reason that I can find in a quick archive search on the topic. These changes to REQUEST-STATUS seem to serve no pratical purpose (What good are 2 "status descriptions" values for 1 REQUEST-STATUS?). Plus they change the legal possible values the property can have which may make iCalendar parsers treat the property as incorrectly formed and thus 'invalid'. "Extending" REQUEST-STATUS for CAP is to be expected but making a fundamental change to the property is NOT. 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 00531AEB85256DDA_= Content-Type: text/html; charset="US-ASCII"
In looking up something related to CALSCALE I noticed that CAP-12-e makes an unmentioned change to iCalendars REQUEST-STATUS property.  This change is NOT good NOR is it necessary.

iCalendar defines REQUEST-STATUS as:

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

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

CAP-12-e proposes changing it to:

   rstatus  = "REQUEST-STATUS" rstatparam ":"
             statcode ";" *(statdesc ) ";" *(extdata)

This makes statdesc optional now PLUS it makes statdesc and extdata both multi valued.  This is a non-backwards compatible change for no apparent reason that I can find in a quick archive search on the topic.  These changes to REQUEST-STATUS seem to serve no pratical purpose (What good are 2 "status descriptions" values for 1 REQUEST-STATUS?).  Plus they change the legal possible values the property can have which may make iCalendar parsers treat the property as incorrectly formed and thus 'invalid'.

"Extending" REQUEST-STATUS for CAP is to be expected but making a fundamental change to the property is NOT.

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 00531AEB85256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 11:21:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27805 for ; Mon, 10 Nov 2003 11:21:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAG0vkT079279 for ; Mon, 10 Nov 2003 08:00:57 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAG0vAC079278 for ietf-calendar-bks; Mon, 10 Nov 2003 08:00:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAG0vkT079273 for ; Mon, 10 Nov 2003 08:00:57 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAC0B23.7060504@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (CALSCALE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 10:41:18 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 11:00:41 AM, Serialize complete at 11/10/2003 11:00:41 AM Content-Type: multipart/alternative; boundary="=_alternative 0055B9E685256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055B9E685256DDA_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/07/2003 04:14:11 PM: > > CALSCALE -- I would like to either see us add a capability > > specification for calendar scales and a special error code for > > unsupported calendar scales, or I would like someone to convince me > > that the absence of such scales isn't really a problem for future > > extensions. What we have right now tells us that there might be other > > calendar scales, but doesn't really tell an implementation how to > > behave if it encounters one. > > iCAL can do a 'REQUEST-STATUS:3.1;Invalid property value;CALSCALE:foo' > now and > seems the correct choice for an unknown CALSCALE. That is the incorrect value to return for REQUEST-STATUS. CALSCALE is NOT invalid! The property is 100% legal on nearly all messages or components where a new calendar would use it (ie: for VCARs "Invalid Property" would be correct but on new VEVENTS is is _valid_). The real 'error' is that the property _value_ is not supported by the recipient. There is a big difference! Unfortunately the new REQUEST-STATUS codes (Section 10.15 Response Codes) are not well organized so its hard to tell exactly what should be sent back. Section 10.15 should define a class of "5.xx" values generically and then fill in as needed. Unfortunately CAP defines some 6.x examples without clearly defining what the 6.xx class actually is (iTIP added the 5.xx class but we didnt define it in iCalendar). The same goes for 7.xx thru 10.xx classes. Heck, CAP decided 10.xx was so important that it skipped 10.0 thru 10.3 and started off with 10.4. A while back the issue of defining the classes was raised and Doug took the task of reorganziing the REQUEST-STATUS values to be more hierarchical rather than flat. After all why do we need 5 new root level classes of errors when we havent even defined them. In response to a CALSCALE:Foo property I would think the CS would send back a: REQUEST-STATUS:3.13;Unsupported component or property found;CALSCALE\:Foo is unknown 3.13 is defined in iTIP and since iCalendar defined CALSCALE as: calscale = "CALSCALE" calparam ":" calvalue CRLF calparam = *(";" xparam) calvalue = "GREGORIAN" / iana-token the CALSCALE:Foo example _IS_ valid since Foo would be classed as an iana-token. It may not be a known token but it is one so "Foo" is NOT invalid, its UNKNOWN. There is a distinct difference. > Until someone proposes a new CALSCALE I do not think we can pre-specify > any behavior. Specifying no behaiviour is likely to get us into the same predicament as we found ourselves in with multiplart MIME in iCalendar. iCalendar didnt directly address it nor did iTIP or iMIP so some CUAs do not support iCalendar/iTIP if its NOT the sole MIME body part in a message. Playing osterich is never good; expectations should be clearly descirbed so the path going forward is not left to the imagination. > Currently there is no way to specify in a request the desired CALSCALE. Um, unless you removed CALSCALE from the payload there certainly is. Any CUA can put in CALSCALE:JAILAI in a REQUEST is sends; thats part of iCalendar & iTIP and thus it better be in CAP too. > Easy > to add, but not something that can break existing CUA's. We are talking about how CAP CUAs should be built. Currently since CAP is not done there are no CAP CUAs or CSs out there to worry about breaking. Currently iCalendar/iTIP have a defined mechanism for conveying CALSCALE. CAP has it too but its NOT clear how each side in the CS / CUA model should behave in some cases when determining supported abilities. Thats the ponit of this discussion I think; to codify the behaviour so that future changes or updates will have a predictable outcome with older implementations. > We could add > text that > says something like 'if you get a CALSCALE that you can not handle in > the CAPABILITY > reply, drop the connection as you can not do anything anyway...' . > However that > is true of (and the point of) the CAPABILITY reply, to find out if you can > interoperate. If you find the other side supports no CALSCALE values that you do, what can you do? Do you ignore it and try to send stuff in an unsupported CALSCALE? Or do you fail gracefully and notify the CU? Or something else? What should a CAP implementation do when someone ignores CALSCALE settings and tries to send something it may not be able to support? We have no defined course of action or value for REQUEST-STATUS. CAP currently says NOTHING on the subject and I think that is a mistake. Sure, there are no current proposals for any new scales now but that is no reason to not take a few minutes to precisely define the expected behaviour going forward. Tim suggestion has merit even if we have nothing on the table now. The blanks in CAP regarding this should be filled in so its not left to future debate over the correct course of action when faced with an unknown CALSCALE will be necessary. 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 0055B9E685256DDA_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/07/2003 04:14:11 PM:
> > CALSCALE -- I would like to either see us add a capability
> > specification for calendar scales and a special error code for
> > unsupported calendar scales, or I would like someone to convince me
> > that the absence of such scales isn't really a problem for future
> > extensions. What we have right now tells us that there might be other
> > calendar scales, but doesn't really tell an implementation how to
> > behave if it encounters one.
>
> iCAL can do a 'REQUEST-STATUS:3.1;Invalid property value;CALSCALE:foo'
> now and
> seems the correct choice for an unknown CALSCALE.
That is the incorrect value to return for REQUEST-STATUS.  CALSCALE is NOT invalid!  The property is 100% legal on nearly all messages or components where a new calendar would use it (ie: for VCARs "Invalid Property" would be correct but on new VEVENTS is is _valid_).  The real 'error' is that the property _value_ is not supported by the recipient.  There is a big difference!

Unfortunately the new REQUEST-STATUS codes (Section 10.15 Response Codes) are not well organized so its hard to tell exactly what should be sent back.  Section 10.15 should define a class of "5.xx" values generically and then fill in as needed.  Unfortunately CAP defines some 6.x examples without clearly defining what the 6.xx class actually is (iTIP added the 5.xx class but we didnt define it in iCalendar).  The same goes for 7.xx thru 10.xx classes.  Heck, CAP decided 10.xx was so important that it skipped 10.0 thru 10.3 and started off with 10.4.

A while back the issue of defining the classes was raised and Doug took the task of reorganziing the REQUEST-STATUS values to be more hierarchical rather than flat.  After all why do we need 5 new root level classes of errors when we havent even defined them.

In response to a CALSCALE:Foo property I would think the CS would send back a:

REQUEST-STATUS:3.13;Unsupported component or property found;CALSCALE\:Foo is unknown

3.13 is defined in iTIP and since iCalendar defined CALSCALE as:

     calscale   = "CALSCALE" calparam ":" calvalue CRLF

    calparam   = *(";" xparam)

    calvalue   = "GREGORIAN" / iana-token

the CALSCALE:Foo example _IS_ valid since Foo would be classed as an iana-token.  It may not be a known token but it is one so "Foo" is NOT invalid, its UNKNOWN.  There is a distinct difference.

> Until someone proposes a new CALSCALE I do not think we can pre-specify
> any behavior.
Specifying no behaiviour is likely to get us into the same predicament as we found ourselves in with multiplart MIME in iCalendar.  iCalendar didnt directly address it nor did iTIP or iMIP so some CUAs do not support iCalendar/iTIP if its NOT the sole MIME body part in a message.  Playing osterich is never good; expectations should be clearly descirbed so the path going forward is not left to the imagination.

> Currently there is no way to specify in a request the desired CALSCALE.

Um, unless you removed CALSCALE from the payload there certainly is.  Any CUA can put in CALSCALE:JAILAI in a REQUEST is sends; thats part of iCalendar & iTIP and thus it better be in CAP too.

>                                                                        Easy
> to add, but not something that can break existing CUA's.

We are talking about how CAP CUAs should be built.  Currently since CAP is not done there are no CAP CUAs or CSs out there to worry about breaking.  Currently iCalendar/iTIP have a defined mechanism for conveying CALSCALE.  CAP has it too but its NOT clear how each side in the CS / CUA model should behave in some cases when determining supported abilities.  Thats the ponit of this discussion I think; to codify the behaviour so that future changes or updates will have a predictable outcome with older implementations.

>                                                            We could add
> text that
> says something like 'if you get a CALSCALE that you can not handle in
> the CAPABILITY
> reply, drop the connection as you can not do anything anyway...' .
> However that
> is true of (and the point of) the CAPABILITY reply, to find out if you can
> interoperate.
If you find the other side supports no CALSCALE values that you do, what can you do?  Do you ignore it and try to send stuff in an unsupported CALSCALE?  Or do you fail gracefully and notify the CU?  Or something else?  What should a CAP implementation do when someone ignores CALSCALE settings and tries to send something it may not be able to support?  We have no defined course of action or value for REQUEST-STATUS.

CAP currently says NOTHING on the subject and I think that is a mistake.  Sure, there are no current proposals for any new scales now but that is no reason to not take a few minutes to precisely define the expected behaviour going forward.  Tim suggestion has merit even if we have nothing on the table now.  The blanks in CAP regarding this should be filled in so its not left to future debate over the correct course of action when faced with an unknown CALSCALE will be necessary.

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 0055B9E685256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 11:58:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00052 for ; Mon, 10 Nov 2003 11:58:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGfNkT080943 for ; Mon, 10 Nov 2003 08:41:23 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAGfNeT080942 for ietf-calendar-bks; Mon, 10 Nov 2003 08:41:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGfLkT080925 for ; Mon, 10 Nov 2003 08:41:22 -0800 (PST) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: Minneapolis Meeting MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 10 Nov 2003 11:41:22 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/10/2003 11:41:23 AM, Serialize complete at 11/10/2003 11:41:23 AM Content-Type: multipart/alternative; boundary="=_alternative 005BAD9885256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BAD9885256DDA_= Content-Type: text/plain; charset="US-ASCII" Because of a sudden death in the family, I have had to cancel my trip to Minneapolis. I have asked Nathaniel Borenstein to chair the Tuesday CALSCH session. He has graciously accepted and if anyone on the list (active or lurking) will be in that session, he will need someone to take minutes or enter data into Jabber. I would appreciate any volunteers that show up. 8-) Again, thanks to everyone for their support of this group. Sorry I won't be there. Pat --=_alternative 005BAD9885256DDA_= Content-Type: text/html; charset="US-ASCII"
Because of a sudden death in the family, I have had to cancel my trip to Minneapolis.  I have asked Nathaniel Borenstein to chair the Tuesday CALSCH session.  He has graciously accepted and  if anyone on the list (active or lurking) will be in that session, he will need someone to take minutes or enter data into Jabber.  I would appreciate any volunteers that show up.  8-)

Again, thanks to everyone for their support of this group.  Sorry I won't be there.

Pat --=_alternative 005BAD9885256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 12:18:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01301 for ; Mon, 10 Nov 2003 12:18:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH1LkT081936 for ; Mon, 10 Nov 2003 09:01:21 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAH1KT0081934 for ietf-calendar-bks; Mon, 10 Nov 2003 09:01:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH1JkT081922 for ; Mon, 10 Nov 2003 09:01:19 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hA9Kvr84025778 for ; Sun, 9 Nov 2003 13:57:53 -0700 (MST) Message-ID: <3FAEAA51.10239C53@INET-Calendar.net> Date: Sun, 09 Nov 2003 13:57:53 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alarms/SEQUENCE (was Re: Status of the CALSCH working group) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Nathaniel Borenstein wrote: > > On Friday, November 7, 2003, at 04:14 PM, Doug Royer wrote: > > Alarms/SEQUENCE -- I remain confused: Can there be two identical objects in the same calendar? If not, we should clearly say so. > > You can and iCAL has no such restriction on any component including VALARMs. > Currently all components have a unique identifier within their context of usage. > Some want no unique identifier, and their stated reasons specifically ignores the > identical components issue. > > But what does this mean? If you store two identical items in your database > without any unique identifiers, how can a client ever choose one over > the other? I'm having a hard time seeing how this is a good idea. -- Nathaniel On my PDA the default entry is audio alarm. I have often accidentally created two audio alarms when I really wanted one audio and one pager (email) alarm. Then had to go back and fix them later when the two alarms go off which when I notice that I made the mistake. If CAP did not allow me to fixed them I have to throw away the entire VEVENT and start over? I hope not. VALARMS need a unique identifier. Think about it, the topic is why would you need to uniquely identify a VALARM in a MODIFY command. One answer is to fix a problem. From owner-ietf-calendar@mail.imc.org Mon Nov 10 12:23:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01727 for ; Mon, 10 Nov 2003 12:22:59 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH2hkT082015 for ; Mon, 10 Nov 2003 09:02:43 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAH2h67082014 for ietf-calendar-bks; Mon, 10 Nov 2003 09:02:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAH2gkT082009 for ; Mon, 10 Nov 2003 09:02:42 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAC0B23.7060504@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 12:02:28 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 12:02:43 PM, Serialize complete at 11/10/2003 12:02:43 PM Content-Type: multipart/alternative; boundary="=_alternative 005D286685256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005D286685256DDA_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/07/2003 04:14:11 PM: > > VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems > > to me that there are several ambiguities here. I think that we must be > > clear about a requirement that servers MUST provide "currently > > accurate" freebusy information in response to an appropriate request. > > And I'm definitely confused about why one would want to permit the use > > of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the > > ITIP syntax for requesting this information. > > Because some want and expect the CU (user) VFREEBUSY and others want the > CALID (calendar) VFREEBUSY. Currently the iTIP method gets the CU VFREEBUSY > that just might be the same as the CALID VFREEBUSY. We have never drawn a distinction between a CUs availability or a calendars before. Are you saying you have some proposal in mind for drawing a distinction? Something like hierarchical calendars with busytime / content rollup or "calendar bundling"? Please say no... CUs like to schedule with other CUs, not with an abstract 'calendar'; I want to meet with Bob, not with a calendar that Bob is an owner or co-owner of or one that Bob has no actual association with but he gave me the RelCALID for. iTIP defined busytime in terms of user interactions because that's how people work. In CAP, the behavior should be the same. To this end CUs are more likely to be targeting the either a particular CU by name or the calFBURL (RFC 2739) for that CU rather than any arbitrary calendar that may be associated somehow to the CU. Early on we had the implicit assumption that each CU had a default calendar where they did their C&S and so a busytime check of that calendar would reflect that users availability; we did not model things such that the users availability was spread out across potentially dozens of calendars. Just like a user does not keep their 'calendar' in separated out across a paper Dayrunner (TM) , a PDA calendar, Voice Mail messages (phone tag arranging) and other non-interlinked sources simply because its not convenient and its easy to miss entries. Trying to draw distinctions beyond how people work in ill-fitting ways is a recipe for disaster and confusion. (RFC 2739 provides calOtherFBURLs for those users who want to have multiple sources but they are not the 'primary' source that calFBURL defines...) Also, busytime should be reflective of the contents of the particular target. A CUA should not be allowed to arbitrary monkey with the VFREEBUSY data that the CS would return so that it is not reflective of the calendar it is associated with. Otherwise when someone does a busytime lookup they see that the target is available from 10AM-11AM today when in fact they are in a meeting which has TRANSP:OPAQUE which defeats the usefulness of busytime AND violates the definition of TRANSP (iCalendar, Section 4.8.2.7 Time Transparency). 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 005D286685256DDA_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/07/2003 04:14:11 PM:
> > VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems
> > to me that there are several ambiguities here. I think that we must be
> > clear about a requirement that servers MUST provide "currently
> > accurate" freebusy information in response to an appropriate request.
> > And I'm definitely confused about why one would want to permit the use
> > of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the
> > ITIP syntax for requesting this information.
>
> Because some want and expect the CU (user) VFREEBUSY and others want the
> CALID (calendar) VFREEBUSY. Currently the iTIP method gets the CU VFREEBUSY
> that just might be the same as the CALID VFREEBUSY.
We have never drawn a distinction between a CUs availability or a calendars before.  Are you saying you have some proposal in mind for drawing a distinction?  Something like hierarchical calendars with busytime / content rollup or "calendar bundling"?  Please say no...

CUs like to schedule with other CUs, not with an abstract 'calendar'; I want to meet with Bob, not with a calendar that Bob is an owner or co-owner of or one that Bob has no actual association with but he gave me the RelCALID for.  iTIP defined busytime in terms of user interactions because that's how people work.  In CAP, the behavior should be the same.  To this end CUs are more likely to be targeting the either a particular CU by name or the calFBURL (RFC 2739) for that CU rather than any arbitrary calendar that may be associated somehow to the CU.  

Early on we had the implicit assumption that each CU had a default calendar where they did their C&S and so a busytime check of that calendar would reflect that users availability; we did not model things such that the users availability was spread out across potentially dozens of calendars.  Just like a user does not keep their 'calendar' in separated out across a paper Dayrunner (TM) , a PDA calendar, Voice Mail messages (phone tag arranging) and other non-interlinked sources simply because its not convenient and its easy to miss entries.  Trying to draw distinctions beyond how people work in ill-fitting ways is a recipe for disaster and confusion.  (RFC 2739 provides calOtherFBURLs for those users who want to have multiple sources but they are not the 'primary' source that calFBURL defines...)

Also, busytime should be reflective of the contents of the particular target.   A CUA should not be allowed to arbitrary monkey with the VFREEBUSY data that the CS would return so that it is not reflective of the calendar it is associated with.  Otherwise when someone does a busytime lookup they see that the target is available from 10AM-11AM today when in fact they are in a meeting which has TRANSP:OPAQUE which defeats the usefulness of busytime AND violates the definition of TRANSP (iCalendar, Section 4.8.2.7 Time Transparency).

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 005D286685256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 12:43:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02751 for ; Mon, 10 Nov 2003 12:43:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAHMNkT082847 for ; Mon, 10 Nov 2003 09:22:23 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAHMNdg082846 for ietf-calendar-bks; Mon, 10 Nov 2003 09:22:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from trout.cpsr.org (trout.cpsr.org [66.180.229.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAHMMkT082840 for ; Mon, 10 Nov 2003 09:22:22 -0800 (PST) (envelope-from nsb@guppylake.com) Received: from guppylake.com (trout [66.180.229.5]) by trout.cpsr.org (8.12.8p2/8.12.8) with ESMTP id hAAHM3ta043453; Mon, 10 Nov 2003 09:22:18 -0800 (PST) (envelope-from nsb@guppylake.com) Date: Mon, 10 Nov 2003 12:23:12 -0500 Subject: Re: Minneapolis Meeting Content-Type: multipart/alternative; boundary=Apple-Mail-62--16520651 Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-calendar@imc.org To: pregen@egenconsulting.com From: Nathaniel Borenstein In-Reply-To: Message-Id: <8FC6B77E-13A2-11D8-84C6-000A9571873E@guppylake.com> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-62--16520651 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable This does lead to an obvious question: Who is showing up? At this=20 point I'm not aware of anyone other than myself who will actually be=20 there.... It could be a very short meeting! -- Nathaniel On Monday, November 10, 2003, at 11:41 AM, pregen@egenconsulting.com=20 wrote: > > Because of a sudden death in the family, I have had to cancel my trip=20= > to Minneapolis. =A0I have asked Nathaniel Borenstein to chair the=20 > Tuesday CALSCH session. =A0He has graciously accepted and =A0if anyone = on=20 > the list (active or lurking) will be in that session, he will need=20 > someone to take minutes or enter data into Jabber. =A0I would = appreciate=20 > any volunteers that show up. =A08-) > > Again, thanks to everyone for their support of this group. =A0Sorry I=20= > won't be there. > > Pat= --Apple-Mail-62--16520651 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This does lead to an obvious question: Who is showing up? At this point I'm not aware of anyone other than myself who will actually be there.... It could be a very short meeting! -- Nathaniel On Monday, November 10, 2003, at 11:41 AM, pregen@egenconsulting.com wrote: HelveticaBecause of a sudden death in the family, I have had to cancel my trip to Minneapolis. =A0I have asked Nathaniel Borenstein to chair the Tuesday CALSCH session. =A0He has graciously accepted and =A0if anyone on the list (active or lurking) will be in that session, he will need someone to take minutes or enter data into Jabber. =A0I would appreciate any volunteers that show up. = =A08-) Again, thanks to everyone for their support of this group. =A0Sorry I won't be there. Pat= --Apple-Mail-62--16520651-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 13:36:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04714 for ; Mon, 10 Nov 2003 13:36:19 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIH0kT086007 for ; Mon, 10 Nov 2003 10:17:00 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAIH0er086006 for ietf-calendar-bks; Mon, 10 Nov 2003 10:17:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIH0kT086001 for ; Mon, 10 Nov 2003 10:17:00 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAC0B23.7060504@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (QUERYID) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 13:16:54 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 01:16:57 PM, Serialize complete at 11/10/2003 01:16:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0063F8ED85256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063F8ED85256DDA_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/07/2003 04:14:11 PM: > > EXPAND and QUERYID -- I am having a hard time understanding how stored > > queries can be useful without search wildcards. Can anyone explain > > this to me? We dropped the ability to auto execute stored queries. > > There is NO restriction that the results of fetching a stored query > return static results (the > same is true for all components) . So I could define (using unspecified > admin tools) a stored > query called 'TODAY' that returns a dynamically returns a VQUERY when > run returns the results of todays events from several calendars. A: There were several questions regarding the usefulness and behaviour of stored queries so the WG (except for Doug) decided to defer the entire concept to post CAP 1.0 so they could be adequately addressed. B: The original intent was to make it easier for 'thin' clients to do normal queries and save them bandwidth and memory footprints. However we never actually had wildcarding in the language (or we lost it at some point) so we failed to fulfil the original intent. C: Anyone can provide a stored VQUERY on their implementation (as an extension to CAP 1.0). Any CUA should be able to retrieve it using CAP 1.0 by simply SEARCHing for the QUERYID:TODAY and the CS should return it. Unfortunately there is nothing in the CAP 1.0 spec that would be able to do this since "today" is a concept that is not encodable using the current query linga. As such doing what Doug suggested results in a VQUERY that exists in the CS that can be referenced by using QUERYID but that is NOT retrievable by the CUA. This means that the user has NO way to know what query "TODAY" is (and its worse if the CS is in a different TZ than the user so they can be in different days when the query is run!). Plus, it is not safe for CUAs to assume or use canned 'special' queries that are not retrievable. Product A's "TODAY" query may be different from Product B's "TODAY" so mixing CUAs and CSs could have incorrect results. > When we had auto-execute, then you could run them without fetching > them. Now you have to fetch them and then run them (I still do not see > why that is better). You dont have to fetch them and then send them back, you simply craft them locally and send them. Its also been demonstrated that the savings in octets is minimal (~50-60 I think) so making ALL CS's implement stored queries is something I find questionable. Also, just how would someone using your CUA that wants to use the stored "TODAY" query work when talking with someone elses CS that does not support stored queries? It would have to construct the query itself and the just send it to the CS. Given the CAP 1.0 query language we have, the CUA must rewrite nearly all queries related to frequently performed operations (ie: What alarms trigger in the next 15 minutes? What entries are on my calendar for Today? etc) so what benefit there may be to stored queries is offset to the degree that the CUA has to rewrite the query and resave it. > All of my requests for such an explanation have been ignored by those > that do not want > the CS to be able to have builtin, stored, or dynamically created > queries. PDAs and > devices on low bandwidth or high latency connections need this feature. Unless all CUAs (thin and fat) have the same fixed list of stored queries that do things that are NOT representable in CAP-Query Language, there is little if any demonstratable savings in keeping stored queries for CAP 1.0 as they were defined. You also neglect to factor in the need of the thin clients to have to rewrite stored queries to keep them accurate (ie: rewrite the bounds of the alarm TRIGGER check every 15 minutes). In addition I see no benefit in relying on remotely stored queries that are not currently encodable in our query language thus unrepresentable in response to this simple SEARCH: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//someone's prodid C: CMD:SEARCH C: TARGET:relcal1 C: BEGIN:VQUERY C: QUERY:SELECT * FROM VQUERY C: WHERE QUERYID >= 'TODAY' C: END:VQUERY C: END:VCALENDAR that are ~product specific and thus non-interoperable (or even in conflict). 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 0063F8ED85256DDA_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/07/2003 04:14:11 PM:
> > EXPAND and QUERYID -- I am having a hard time understanding how stored
> > queries can be useful without search wildcards. Can anyone explain
> > this to me? We dropped the ability to auto execute stored queries.
>
> There is NO restriction that the results of fetching a stored query
> return static results (the
>  same is true for all components) . So I could define (using unspecified
> admin tools) a stored
> query called 'TODAY' that returns a dynamically returns a VQUERY when
> run returns the results of todays events from several calendars.
A: There were several questions regarding the usefulness and behaviour of stored queries so the WG (except for Doug) decided to defer the entire concept to post CAP 1.0 so they could be adequately addressed.

B: The original intent was to make it easier for 'thin' clients to do normal queries and save them bandwidth and memory footprints.  However we never actually had wildcarding in the language (or we lost it at some point) so we failed to fulfil the original intent.

C: Anyone can provide a stored VQUERY on their implementation (as an extension to CAP 1.0).  Any CUA should be able to retrieve it using CAP 1.0 by simply SEARCHing for the QUERYID:TODAY and the CS should return it.  Unfortunately there is nothing in the CAP 1.0 spec that would be able to do this since "today" is a concept that is not encodable using the current query linga.  As such doing what Doug suggested results in a VQUERY that exists in the CS that can be referenced by using QUERYID but that is NOT retrievable by the CUA.  This means that the user has NO way to know what query "TODAY" is (and its worse if the CS is in a different TZ than the user so they can be in different days when the query is run!).  Plus, it is not safe for CUAs to assume or use canned 'special' queries that are not retrievable.  Product A's "TODAY" query may be different from Product B's "TODAY" so mixing CUAs and CSs could have incorrect results.

> When we had auto-execute, then you could run them without fetching
> them. Now you have to fetch them and then run them (I still do not see
> why that is better).

You dont have to fetch them and then send them back, you simply craft them locally and send them.  Its also been demonstrated that the savings in octets is minimal (~50-60 I think) so making ALL CS's implement stored queries is something I find questionable.  Also, just how would someone using your CUA that wants to use the stored "TODAY" query work when talking with someone elses CS that does not support stored queries?  It would have to construct the query itself and the just send it to the CS.

Given the CAP 1.0 query language we have, the CUA must rewrite nearly all queries related to frequently performed operations (ie: What alarms trigger in the next 15 minutes? What entries are on my calendar for Today? etc) so what benefit there may be to stored queries is offset to the degree that the CUA has to rewrite the query and resave it.

> All of my requests for such an explanation have been ignored by those
> that do not want
> the CS to be able to have builtin, stored, or dynamically created
> queries. PDAs and
> devices on low bandwidth or high latency connections need this feature.
Unless all CUAs (thin and fat) have the same fixed list of stored queries that do things that are NOT representable in CAP-Query Language, there is little if any demonstratable savings in keeping stored queries for CAP 1.0 as they were defined.  

You also neglect to factor in the need of the thin clients to have to rewrite stored queries to keep them accurate (ie: rewrite the bounds of the alarm TRIGGER check every 15 minutes).  

In addition I see no benefit in relying on remotely stored queries that are not currently encodable in our query language thus unrepresentable in response to this simple SEARCH:

      C: Content-Type: text/calendar
     C:
     C: BEGIN:VCALENDAR
     C: VERSION:2.0
     C: PRODID:-//someone's prodid
     C: CMD:SEARCH
     C: TARGET:relcal1
     C: BEGIN:VQUERY
     C: QUERY:SELECT * FROM VQUERY
     C:  WHERE QUERYID >= 'TODAY'
     C: END:VQUERY
     C: END:VCALENDAR

that are ~product specific and thus non-interoperable (or even in conflict).

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 0063F8ED85256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 13:44:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04915 for ; Mon, 10 Nov 2003 13:44:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIObkT086369 for ; Mon, 10 Nov 2003 10:24:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAIOb30086368 for ietf-calendar-bks; Mon, 10 Nov 2003 10:24:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIOakT086362 for ; Mon, 10 Nov 2003 10:24:37 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAC0B23.7060504@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (EXPAND) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 13:21:37 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 01:24:33 PM, Serialize complete at 11/10/2003 01:24:33 PM Content-Type: multipart/alternative; boundary="=_alternative 0064677085256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064677085256DDA_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/07/2003 04:14:11 PM: > > EXPAND and QUERYID -- I am having a hard time understanding how stored > > queries can be useful without search wildcards. Can anyone explain > > this to me? We dropped the ability to auto execute stored queries. > > There is NO restriction that the results of fetching a stored query > return static results (the > same is true for all components) . So I could define (using unspecified > admin tools) a stored > query called 'TODAY' that returns a dynamically returns a VQUERY when > run returns the results of todays events from several calendars. > > When we had auto-execute, then you could run them without fetching > them. Now you have to fetch them and then run them (I still do not see > why that is better). > All of my requests for such an explanation have been ignored by those > that do not want > the CS to be able to have builtin, stored, or dynamically created > queries. PDAs and > devices on low bandwidth or high latency connections need this feature. To date I have not heard a response from Doug or anyone who can answer my question about EXPAND. It was a simple question but there seems to be reluctance to answer it. So Ill ask again... With regards to EXPAND, is the CS supposed to return literally all instances of a repeating entry even if they fall outside the bounds of the parameters in the VQUERY or is the stated intention of EXPAND incorrectly / poorly phrase? 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 0064677085256DDA_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/07/2003 04:14:11 PM:
> > EXPAND and QUERYID -- I am having a hard time understanding how stored
> > queries can be useful without search wildcards. Can anyone explain
> > this to me? We dropped the ability to auto execute stored queries.
>
> There is NO restriction that the results of fetching a stored query
> return static results (the
>  same is true for all components) . So I could define (using unspecified
> admin tools) a stored
> query called 'TODAY' that returns a dynamically returns a VQUERY when
> run returns the results of todays events from several calendars.
>
> When we had auto-execute, then you could run them without fetching
> them. Now you have to fetch them and then run them (I still do not see
> why that is better).
> All of my requests for such an explanation have been ignored by those
> that do not want
> the CS to be able to have builtin, stored, or dynamically created
> queries. PDAs and
> devices on low bandwidth or high latency connections need this feature.
To date I have not heard a response from Doug or anyone who can answer my question about EXPAND.  It was a simple question but there seems to be reluctance to answer it.  So Ill ask again...

With regards to EXPAND, is the CS supposed to return literally all instances of a repeating entry even if they fall outside the bounds of the parameters in the VQUERY or is the stated intention of EXPAND incorrectly / poorly phrase?

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 0064677085256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 14:07:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06191 for ; Mon, 10 Nov 2003 14:07:57 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIk1kT087259 for ; Mon, 10 Nov 2003 10:46:01 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAIk1Lu087258 for ietf-calendar-bks; Mon, 10 Nov 2003 10:46:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAIk0kT087252 for ; Mon, 10 Nov 2003 10:46:00 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAC0B23.7060504@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 13:43:13 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 01:45:56 PM, Serialize complete at 11/10/2003 01:45:56 PM Content-Type: multipart/alternative; boundary="=_alternative 0066618885256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066618885256DDA_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/07/2003 04:14:11 PM: > > Alarms/SEQUENCE -- I remain confused: Can there be two identical > > objects in the same calendar? If not, we should clearly say so. > > You can and iCAL has no such restriction on any component including VALARMs. Sorry, iCalendar does state that multiple repeat instances at the same date/time are to be considered one: Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. at least 4 times. There is also : 4. When the combination of the "RRULE" and "RDATE" properties on an iCalendar object produces multiple instances having the same start date/time, they should be collapsed to, and considered as, a single instance. in case you missed the other occurances. You also expliclty restrictions in CAP with: There MUST NOT BE more than one "BOOKED" state object in a calendar for the same "UID". The "ADD" method value may create multiple objects all in the "BOOKED" state for the same UID, however for the purpose of this memo, they are the same object that simply have multiple "VCALENDAR" components. Essentially this says that there can not be any identical VEVENTS with the same identifier that are BOOKD. Its interesting to note that CAP disallows it with "MUST NOT" but then goes on to say "may". The first line was correct, the later text removes the restriction of sorts and is bad. I have yet to hear any good justification for allowing "identical but separate" VALARMs that match any practical view of things. Despite Dougs and Marks claim, the only reason to have SEQUENCE (or ALARMID) on VALARMs is for this rare usage case that currently noone actually has nor models anyones actual behaviour or needs. Id like to apply KISS to this and move CAP along... (Just like we disallow multiple copies of the same booked entry, the same should go for alarms). > Currently all components have a unique identifier within their context > of usage. Not totally true. An example of this is VDAYLIGHTs and VSTANDARDs in a VTIMEZONE. The TZID of the VTIMEZONE is unique but the TZNAME (akin to its identifier) is not unique. In fact the correct VDAYLIGHT/VSTANDARD is found by selecting the subcomponent criteria that meet the requestors needs (ie: when its in effect). The ONLY case that seems to be demonstratable for SEQUENCE (nay, ALARMID) is the case where there are multiple, identical VALARMs whose existance is somewhat questionable, at least for me. 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 0066618885256DDA_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/07/2003 04:14:11 PM:
> > Alarms/SEQUENCE -- I remain confused: Can there be two identical
> > objects in the same calendar? If not, we should clearly say so.
>
> You can and iCAL has no such restriction on any component including VALARMs.
Sorry, iCalendar does state that multiple repeat instances at the same date/time are to be considered one:

                                                          Where
  duplicate instances are generated by the "RRULE" and "RDATE"
  properties, only one recurrence is considered. Duplicate instances
  are ignored.

at least 4 times.  There is also :

   4.  When the combination of the "RRULE" and "RDATE" properties on an
      iCalendar object produces multiple instances having the same
      start date/time, they should be collapsed to, and considered as,
      a single instance.

in case you missed the other occurances.  

You also expliclty restrictions in CAP with:

   There MUST NOT BE more than one "BOOKED" state object in a calendar
  for the same "UID". The "ADD" method value may create multiple
  objects all in the "BOOKED" state for the same UID, however for the
  purpose of this memo, they are the same object that simply have
  multiple "VCALENDAR" components.

Essentially this says that there can not be any identical VEVENTS with the same identifier that are BOOKD.  Its interesting to note that CAP disallows it with "MUST NOT" but then goes on to say "may".   The first line was correct, the later text removes the restriction of sorts and is bad.

I have yet to hear any good justification for allowing "identical but separate" VALARMs that match any practical view of things.  Despite Dougs and Marks claim, the only reason to have SEQUENCE (or ALARMID) on VALARMs is for this rare usage case that currently noone actually has nor models anyones actual behaviour or needs.  Id like to apply KISS to this and move CAP along...  (Just like we disallow multiple copies of the same booked entry, the same should go for alarms).

> Currently all components have a unique identifier within their context
> of usage.
Not totally true.  An example of this is VDAYLIGHTs and VSTANDARDs in a VTIMEZONE.  The TZID of the VTIMEZONE is unique but the TZNAME (akin to its identifier) is not unique.  In fact the correct VDAYLIGHT/VSTANDARD is found by selecting the subcomponent criteria that meet the requestors needs (ie: when its in effect).

The ONLY case that seems to be demonstratable for SEQUENCE (nay, ALARMID) is the case where there are multiple, identical VALARMs whose existance is somewhat questionable, at least for me.

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 0066618885256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:17:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10925 for ; Mon, 10 Nov 2003 15:16:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAJiKkT089743 for ; Mon, 10 Nov 2003 11:44:20 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAJiK3u089742 for ietf-calendar-bks; Mon, 10 Nov 2003 11:44:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAJiIkT089737 for ; Mon, 10 Nov 2003 11:44:18 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAAJiFXK015186 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 11:44:17 -0800 Message-ID: <3FAFEA8A.5020602@Royer.com> Date: Mon, 10 Nov 2003 12:44:10 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (QUERYID) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020203050606010800030701" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020203050606010800030701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/07/2003 04:14:11 PM: > > > EXPAND and QUERYID -- I am having a hard time understanding how > stored > > > queries can be useful without search wildcards. Can anyone explain > > > this to me? We dropped the ability to auto execute stored queries. > > > > There is NO restriction that the results of fetching a stored query > > return static results (the > > same is true for all components) . So I could define (using > unspecified > > admin tools) a stored > > query called 'TODAY' that returns a dynamically returns a VQUERY when > > run returns the results of todays events from several calendars. > > A: There were several questions regarding the usefulness and behaviour > of stored queries so the WG (except for Doug) decided to defer the > entire concept to post CAP 1.0 so they could be adequately addressed. And they were. > > B: The original intent was to make it easier for 'thin' clients to do > normal queries and save them bandwidth and memory footprints. However > we never actually had wildcarding in the language (or we lost it at > some point) so we failed to fulfil the original intent. As pointed out on the list bandwidth limiting is not nessasasarly tied to wildcards. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020203050606010800030701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTEwMTk0NDEwWjAjBgkqhkiG9w0BCQQxFgQUfrn9fIIfvGEbUGPz/T8w GMET/g0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA4XEz78tgHuqHFXm6m2k89syfaUXWkb4m8xp9dSUhI5L6Aq63e+9LDK0jZYIJJhH6 VdOWDsXxgkdZz3t/R3xE102GMGyur/G8TLBjKPRQXiNXnqa5mxc8MY3hIPh4yRLmMhRB412k u9Uvr3OYjK8OMN/fL7twIoraElbDTMlh+L6cNWCaJ+TwRlMfTUKJYiVtN8F77AWzWliRzSVR lZfehScCyhhnwT2cZAkVzd9KAwrr+iBKePI2XiqxTFwBsZxFrH510XbkCj8WDSlVSAC/iILN fQplqyjeNxeqwIDZ+D3aLlXe2ujanRViEcUHdWNDsaUayE0hoNYfm6sjGmTGEQAAAAAAAA== --------------ms020203050606010800030701-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:20:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11262 for ; Mon, 10 Nov 2003 15:20:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAJxHkT090123 for ; Mon, 10 Nov 2003 11:59:17 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAJxG0J090122 for ietf-calendar-bks; Mon, 10 Nov 2003 11:59:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAJxGkT090110 for ; Mon, 10 Nov 2003 11:59:16 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAEAA51.10239C53@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: Alarms/SEQUENCE (was Re: Status of the CALSCH working group) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 14:44:03 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 02:59:08 PM, Serialize complete at 11/10/2003 02:59:08 PM Content-Type: multipart/alternative; boundary="=_alternative 006BF37C85256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006BF37C85256DDA_= Content-Type: text/plain; charset="US-ASCII" Mark replied on 11/09/2003 03:57:53 PM: > On my PDA the default entry is audio alarm. I have often accidentally > created two audio alarms when I really wanted one audio and one pager > (email) alarm. Then had to go back and fix them later when the > two alarms go off which when I notice that I made the mistake. > > If CAP did not allow me to fixed them I have to throw away > the entire VEVENT and start over? I hope not. Unless they are exactly the same then identifying the one you want to remove is trivial. Also, if VALARMs were treated like VEVENTs: There MUST NOT BE more than one "BOOKED" state object in a calendar for the same "UID". and later: 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. then you'd never have this problem since the duplicate AUDIO alarm would not be created to begin with. Im assuming its duplicate even though you did not actually say this. > VALARMS need a unique identifier. Think about it, the topic is > why would you need to uniquely identify a VALARM in a MODIFY command. > One answer is to fix a problem. The ONLY reason a VALARM would need to have a unique identifier is if we allowed exact duplicate VALARMs (a questionable decision given the other prohibitions in iCalendar and CAP and the usage scenarios for it). I have already shown that the MODIFY command does NOT need to include any identifier in order to modify a particular VALARM; the CUA simply needs to send enough VALARM properties to uniquely identify the VALARM in question. If we do decide that we want to allow duplicate VALARMs per component then more questions arise. Other related questions related to addition to iCalendar include: 1: If there is no ALARMID / SEQUENCE property on a VALARM, does the CUA need to assign one? An example of this is an entry that is created outside of CAP and delivered to the CU. 2: If the ALARMID / SEQUENCE property can be locally assigned for entries that originate elsewhere then are they preserved when the entry is sent to someone else (ie: The CU delegates the VEVENT)? 3: Just how is the fact that the VALARM is NOT "local" to the CU (ie: it came with the REQUEST) but the ALARMID / SEQUENCE value IS "local" tracked? Do we now have to add a new property parameter to ALARMID / SEQUENCE to track this too? 4: If exact duplicate VALARMs are 'legal' then how do we resolve the case where the sender included multiple exact duplicates with no ALARMID / SEQUENCE? There is no way to initially distinguish between the two so a MODIFY command MUST fail by: If the CS can not find a component that matches the QUERY and does not have at least all of the OLD-VALUES, then a 6.1 error is returned. because there was no unique match on all the old-values. Catch-22. The simpler solution is to prohibit exact duplicate VALARMs on any particular component and all the problems or questions can go away. 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 006BF37C85256DDA_= Content-Type: text/html; charset="US-ASCII"
Mark replied on 11/09/2003 03:57:53 PM:
> On my PDA the default entry is audio alarm. I have often accidentally
> created two audio alarms when I really wanted one audio and one pager
> (email) alarm. Then had to go back and fix them later when the
> two alarms go off which when I notice that I made the mistake.
>
> If CAP did not allow me to fixed them I have to throw away
> the entire VEVENT and start over? I hope not.
Unless they are exactly the same then identifying the one you want to remove is trivial.  Also, if VALARMs were treated like VEVENTs:

   There MUST NOT BE more than one "BOOKED" state object in a calendar
  for the same "UID".

and later:

                                                    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.

then you'd never have this problem since the duplicate AUDIO alarm would not be created to begin with.  Im assuming its duplicate even though you did not actually say this.

> VALARMS need a unique identifier. Think about it, the topic is
> why would you need to uniquely identify a VALARM in a MODIFY command.
> One answer is to fix a problem.
The ONLY reason a VALARM would need to have a unique identifier is if we allowed exact duplicate VALARMs (a questionable decision given the other prohibitions in iCalendar and CAP and the usage scenarios for it).  I have already shown that the MODIFY command does NOT need to include any identifier in order to modify a particular VALARM; the CUA simply needs to send enough VALARM properties to uniquely identify the VALARM in question.

If we do decide that we want to allow duplicate VALARMs per component then more questions arise.  Other related questions related to addition to iCalendar include:

1: If there is no ALARMID / SEQUENCE property on a VALARM, does the CUA need to assign one?  An example of this is an entry that is created outside of CAP and delivered to the CU.

2: If the ALARMID / SEQUENCE property can be locally assigned for entries that originate elsewhere then are they preserved when the entry is sent to someone else (ie: The CU delegates the VEVENT)?  

3: Just how is the fact that the VALARM is NOT "local" to the CU (ie: it came with the REQUEST) but the ALARMID / SEQUENCE value IS "local" tracked?  Do we now have to add a new property parameter to ALARMID / SEQUENCE to track this too?

4: If exact duplicate VALARMs are 'legal' then how do we resolve the case where the sender included multiple exact duplicates with no ALARMID / SEQUENCE?  There is no way to initially distinguish between the two so a MODIFY command MUST fail by:

                                                                  If
  the CS can not find a component that matches the QUERY and does not
  have at least all of the OLD-VALUES, then a 6.1 error is returned.
because there was no unique match on all the old-values.  Catch-22.  The simpler solution is to prohibit exact duplicate VALARMs on any particular component and all the problems or questions can go away.

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 006BF37C85256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:21:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11319 for ; Mon, 10 Nov 2003 15:21:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAJsVkT089939 for ; Mon, 10 Nov 2003 11:54:31 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAJsVVA089938 for ietf-calendar-bks; Mon, 10 Nov 2003 11:54:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAJsTkT089933 for ; Mon, 10 Nov 2003 11:54:30 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAAJsQXK015330 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 11:54:27 -0800 Message-ID: <3FAFECED.4090905@Royer.com> Date: Mon, 10 Nov 2003 12:54:21 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Changing REQUEST-STATUS References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060704020503090404010600" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060704020503090404010600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I remember at or before -00 time, we had a problem with the iCAL version of REQUEST-STATUS and how it effected some error handling. Fixing REQUEST-STATUS was one of the todo items for CAP. Still looking through archives... I am guessing it was just fixed incorrectly and no one noticed since -08. As in -07 it was incorrectly: statcode [";" statdesc [";" extdata]] I am guessing the incorrect ABNF got incorrectly fixed. Bruce_Kahn@notesdev.ibm.com wrote: > > In looking up something related to CALSCALE I noticed that CAP-12-e > makes an unmentioned change to iCalendars REQUEST-STATUS property. > This change is NOT good NOR is it necessary. If you would have looked closer it was not mentioned in -12-e becaues it did not change in -12-e. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060704020503090404010600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTEwMTk1NDIxWjAjBgkqhkiG9w0BCQQxFgQUVoOhQUUZxLMv0iKVlahh bjOS/HYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAKlNR45bjFl+PC91piID++slMUAANERKZqEts0ODEPxzyGKEIL9TOYhx9fjR1VdP5 w9kB19WBXh2I8nMrAoHQauU3/G0xgKdkzWNK8kBpJusqiPOru9iJXWS0kJviHPMNpETm8MYe c9uNC2L8Fnecordyl65qEUQp77AQ76uM2qI7bgd9Wz7mi9Hs6nV6xWA1qPmdkUVKL1ceTfoR FQxT/VCjQcfQCGYCaHJQ6IyD8L5+QvHa7X/CN6OhwPZD6m0csVq+Saloff7FgllL4KIOkZjB PmUbPn1dWyqv9H/6zNVW0/mIyEyDQimUEFv9ravkYQuLd9sApWutp+QUCEv2WgAAAAAAAA== --------------ms060704020503090404010600-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:25:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11458 for ; Mon, 10 Nov 2003 15:25:32 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK7QkT090396 for ; Mon, 10 Nov 2003 12:07:26 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAK7Q9l090395 for ietf-calendar-bks; Mon, 10 Nov 2003 12:07:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK7PkT090389 for ; Mon, 10 Nov 2003 12:07:25 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAAK7M84027555 for ; Mon, 10 Nov 2003 13:07:22 -0700 (MST) Message-ID: <3FAFEFF9.C58F4ECB@INET-Calendar.net> Date: Mon, 10 Nov 2003 13:07:21 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (EXPAND) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > With regards to EXPAND, is the CS supposed to return literally all > instances of a repeating entry even if they fall outside the bounds of > the parameters in the VQUERY or is the stated intention of EXPAND > incorrectly / poorly phrase? Yes - return unlimited instances until you servers crashe. Did you really need an answer? From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:25:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11474 for ; Mon, 10 Nov 2003 15:25:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK6AkT090355 for ; Mon, 10 Nov 2003 12:06:10 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAK6AfU090354 for ietf-calendar-bks; Mon, 10 Nov 2003 12:06:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK69kT090347 for ; Mon, 10 Nov 2003 12:06:09 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAAK6584027552 for ; Mon, 10 Nov 2003 13:06:05 -0700 (MST) Message-ID: <3FAFEFAD.13B851B9@INET-Calendar.net> Date: Mon, 10 Nov 2003 13:06:05 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (QUERYID) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/07/2003 04:14:11 PM: > > > EXPAND and QUERYID -- I am having a hard time understanding how > stored > > > queries can be useful without search wildcards. Can anyone explain > > > > this to me? We dropped the ability to auto execute stored queries. > > > > There is NO restriction that the results of fetching a stored query > > return static results (the > > same is true for all components) . So I could define (using > unspecified > > admin tools) a stored > > query called 'TODAY' that returns a dynamically returns a VQUERY > when > > run returns the results of todays events from several calendars. > > A: There were several questions regarding the usefulness and behaviour > of stored queries so the WG (except for Doug) decided to defer the > entire concept to post CAP 1.0 so they could be adequately addressed. No, you simply bullied the list into droping auto executed queries. Re-read the archives. From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:26:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11527 for ; Mon, 10 Nov 2003 15:26:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK43kT090305 for ; Mon, 10 Nov 2003 12:04:03 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAK42pS090304 for ietf-calendar-bks; Mon, 10 Nov 2003 12:04:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK41kT090299 for ; Mon, 10 Nov 2003 12:04:01 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAAK3w84027545 for ; Mon, 10 Nov 2003 13:03:58 -0700 (MST) Message-ID: <3FAFEF2E.BB9BA57B@INET-Calendar.net> Date: Mon, 10 Nov 2003 13:03:58 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > We have never drawn a distinction between a CUs availability or a > calendars before. Are you saying you have some proposal in mind for > drawing a distinction? Something like hierarchical calendars with > busytime / content rollup or "calendar bundling"? Please say no... So what - what he said is still true. Currently MANY systems PUBLISH freebusy, including the big vendor - please say you do not want to break them!!! From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:30:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11808 for ; Mon, 10 Nov 2003 15:30:59 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK9qkT090463 for ; Mon, 10 Nov 2003 12:09:52 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAK9qsv090462 for ietf-calendar-bks; Mon, 10 Nov 2003 12:09:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK9pkT090455 for ; Mon, 10 Nov 2003 12:09:51 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAAK9m84027559 for ; Mon, 10 Nov 2003 13:09:48 -0700 (MST) Message-ID: <3FAFF08C.48C6A51B@INET-Calendar.net> Date: Mon, 10 Nov 2003 13:09:48 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 11/07/2003 04:14:11 PM: > > > Alarms/SEQUENCE -- I remain confused: Can there be two identical > > > objects in the same calendar? If not, we should clearly say so. > > > > You can and iCAL has no such restriction on any component including > VALARMs. > > Sorry, iCalendar does state that multiple repeat instances at the same > date/time are to be considered one: > What does that have to do with the topic or the email asked or answered? Nothing at all. Do you even follow the topics before posting? From owner-ietf-calendar@mail.imc.org Mon Nov 10 15:32:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11930 for ; Mon, 10 Nov 2003 15:32:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAKBAkT090533 for ; Mon, 10 Nov 2003 12:11:10 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAKBADl090532 for ietf-calendar-bks; Mon, 10 Nov 2003 12:11:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAKB9kT090527 for ; Mon, 10 Nov 2003 12:11:09 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAAKB684027566 for ; Mon, 10 Nov 2003 13:11:06 -0700 (MST) Message-ID: <3FAFF0DA.FE988D98@INET-Calendar.net> Date: Mon, 10 Nov 2003 13:11:06 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alarms/SEQUENCE (was Re: Status of the CALSCH working group) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > If CAP did not allow me to fixed them I have to throw away > > the entire VEVENT and start over? I hope not. > > Unless they are exactly the same then identifying the one you want to > remove is trivial. Also, if VALARMs were treated like VEVENTs: > Again - did you read the topic and email before posting? That WAS the topic - them being the same. From owner-ietf-calendar@mail.imc.org Mon Nov 10 16:22:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14196 for ; Mon, 10 Nov 2003 16:22:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK1MkT090238 for ; Mon, 10 Nov 2003 12:01:22 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAK1Mi9090237 for ietf-calendar-bks; Mon, 10 Nov 2003 12:01:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK1KkT090229 for ; Mon, 10 Nov 2003 12:01:21 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAAK1H84027541 for ; Mon, 10 Nov 2003 13:01:17 -0700 (MST) Message-ID: <3FAFEE8D.42890E16@INET-Calendar.net> Date: Mon, 10 Nov 2003 13:01:17 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Versioning) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Unfortunately CAP does not say much more on the topic of using > versions which means there is no clearly defined behaviour or > expectations for CAP 1.0 implementations to follow in a consistant > manner. Again you must be reading a version of CAP with text missing. Try re-downloading the version that explains it. > Currently it is not a list of supported versions of CAP, it is a > single valued property with no clearly defined behaviour for going > forward. The issue of the "1.0" (pre-July 2003) vs "XXXX" RFC number > (~July 2003) value change is secondary to the funcational questions of > it. Again you must have missed the text that calles it multivalued. > > > So I do not think it has the same problem as the MIME-Version and > iCAL > > VERSION properties. > > The problem is compound: > > 1: The property is currently single valued, not multivalued. Not true == please read CAP before posting. > 2: The property has no clear definition of dealing with multiple > values (ie: what is the expected or recommended behaviour if multiple > values are found). Not true == please read CAP before posting. From owner-ietf-calendar@mail.imc.org Mon Nov 10 16:27:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14329 for ; Mon, 10 Nov 2003 16:27:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAKqgkT092001 for ; Mon, 10 Nov 2003 12:52:42 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAKqgXF092000 for ietf-calendar-bks; Mon, 10 Nov 2003 12:52:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAKqekT091993 for ; Mon, 10 Nov 2003 12:52:41 -0800 (PST) (envelope-from satyanarayana.vempati@Sun.COM) Received: from phys-ha13sca-1 ([129.145.155.91]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAKqX60017735 for ; Mon, 10 Nov 2003 13:52:42 -0700 (MST) Received: from pranav (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HO50051TLZT5X@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Mon, 10 Nov 2003 12:52:41 -0800 (PST) Date: Mon, 10 Nov 2003 12:52:47 -0800 From: Satya Vempati Subject: RE: Status of the CALSCH working group (Alarms/SEQUENCE) In-reply-to: <3FAFF08C.48C6A51B@INET-Calendar.net> To: ietf-calendar@imc.org Message-id: <004101c3a7cc$9917d9f0$6d9012c0@red.iplanet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would like to suggest that everyone should make a conscious effort to keep the discussion productive and not give way to acrimony. We need to keep in mind that these archives have to be of some use to people who, in future, browse them for information and answers. Most of the recent posts are nothing but invective and as such should not posted to a technical public forum such as this one. -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Mark Smith Sent: Monday, November 10, 2003 12:10 PM To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 11/07/2003 04:14:11 PM: > > > Alarms/SEQUENCE -- I remain confused: Can there be two identical > > > objects in the same calendar? If not, we should clearly say so. > > > > You can and iCAL has no such restriction on any component including > VALARMs. > > Sorry, iCalendar does state that multiple repeat instances at the same > date/time are to be considered one: > What does that have to do with the topic or the email asked or answered? Nothing at all. Do you even follow the topics before posting? From owner-ietf-calendar@mail.imc.org Mon Nov 10 16:48:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15269 for ; Mon, 10 Nov 2003 16:48:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALQPkT093216 for ; Mon, 10 Nov 2003 13:26:25 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAALQPuo093215 for ietf-calendar-bks; Mon, 10 Nov 2003 13:26:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALQOkT093209 for ; Mon, 10 Nov 2003 13:26:24 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAALQL84027675 for ; Mon, 10 Nov 2003 14:26:21 -0700 (MST) Message-ID: <3FB0027D.A5EBB973@INET-Calendar.net> Date: Mon, 10 Nov 2003 14:26:21 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alarms/SEQUENCE (was Re: Status of the CALSCH working group) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark replied on 11/09/2003 03:57:53 PM: > > On my PDA the default entry is audio alarm. I have often > accidentally > > created two audio alarms when I really wanted one audio and one > pager > > (email) alarm. Then had to go back and fix them later when the > > two alarms go off which when I notice that I made the mistake. > > > > If CAP did not allow me to fixed them I have to throw away > > the entire VEVENT and start over? I hope not. > > Unless they are exactly the same then identifying the one you want to > remove is trivial. Also, if VALARMs were treated like VEVENTs: > > There MUST NOT BE more than one "BOOKED" state object in a calendar > for the same "UID". Do you bother reading this email? The topic is multiple VALARMS in one VEVENT, not multiple VEVENTS. From owner-ietf-calendar@mail.imc.org Mon Nov 10 16:55:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15557 for ; Mon, 10 Nov 2003 16:55:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALc4kT093518 for ; Mon, 10 Nov 2003 13:38:04 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAALc4kB093517 for ietf-calendar-bks; Mon, 10 Nov 2003 13:38:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALc2kT093506 for ; Mon, 10 Nov 2003 13:38:02 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAALbx84027691 for ; Mon, 10 Nov 2003 14:37:59 -0700 (MST) Message-ID: <3FB00537.DA86921F@INET-Calendar.net> Date: Mon, 10 Nov 2003 14:37:59 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Status of CAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit If I accidently create two identical VALARMS in one sequence I want to be able to modify one of them to be correct. As far as I an tell Bruces repeated inability to respoind to that point and his repeated inability to comprehend that this list does not report to him is what is keeping this item open. So if there are two of the same VALARMS in the SAME VEVENT. If you remove SEQUENCE, they can not be fixed. Can anyone show this to be incorrect? On the topic of CAP-VERSION: Does anyone agree with Bruce when he says it is single valued? On the topic of the QUERY-ID, does anyone think that a component like VQUERY having a unique identifies the same as auto exectution of a VQUERY? From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:01:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16126 for ; Mon, 10 Nov 2003 17:01:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALfKkT093603 for ; Mon, 10 Nov 2003 13:41:20 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAALfKK5093602 for ietf-calendar-bks; Mon, 10 Nov 2003 13:41:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALfJkT093597 for ; Mon, 10 Nov 2003 13:41:20 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAFEF2E.BB9BA57B@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 16:32:59 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 04:41:07 PM, Serialize complete at 11/10/2003 04:41:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0075EB4285256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075EB4285256DDA_= Content-Type: text/plain; charset="US-ASCII" Mark said on 11/10/2003 03:03:58 PM: > So what - what he said is still true. Currently MANY systems > PUBLISH freebusy, including the big vendor - please say you > do not want to break them!!! In case you've never actually used their product, the model is that the entire process is user centric, not some abstract calendar that can be linked but to someone but not necessarily the contents of that calendar. They use a single calendar model and their CUA pushes the busytime out as necessary to a configured place. The "contacts" have a URL where the client can go get busytime data for a particular contact w/o doing any actual iTIP REQUEST/REPLY. So are you are proposing we change CAP and iTIP to follow their direct access model of busytime? Busytime is UPN or CU focused and in RFC 2739 we defined a couple URI to use in protocols like CAP for doing busytime query for users. Doug sounded like he had a different model of busytime but didnt quite say so (nor has he clarified yet). In any case, the format of the query can still be iTIP but query is done via the capFBURL rather than a email address in an iMIP message. Thats why Frank defined those properties in 2739 for us... Are you suggesting we make busytime relcalid focused and not user focused?? 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 0075EB4285256DDA_= Content-Type: text/html; charset="US-ASCII"
Mark said on 11/10/2003 03:03:58 PM:
> So what - what he said is still true. Currently MANY systems
> PUBLISH freebusy, including the big vendor - please say you
> do not want to break them!!!
In case you've never actually used their product, the model is that the entire process is user centric, not some abstract calendar that can be linked but to someone but not necessarily the contents of that calendar.  They use a single calendar model and their CUA pushes the busytime out as necessary to a configured place.  The "contacts" have a URL where the client can go get busytime data for a particular contact w/o doing any actual iTIP REQUEST/REPLY.  So are you are proposing we change CAP and iTIP to follow their direct access model of busytime?

Busytime is UPN or CU focused and in RFC 2739 we defined a couple URI to use in protocols like CAP for doing busytime query for users.  Doug sounded like he had a different model of busytime but didnt quite say so (nor has he clarified yet).  In any case, the format of the query can still be iTIP but query is done via the capFBURL rather than a email address in an iMIP message.  Thats why Frank defined those properties in 2739 for us...

Are you suggesting we make busytime relcalid focused and not user focused??

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 0075EB4285256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:10:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16805 for ; Mon, 10 Nov 2003 17:09:59 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALs1kT094125 for ; Mon, 10 Nov 2003 13:54:01 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAALs1Lk094124 for ietf-calendar-bks; Mon, 10 Nov 2003 13:54:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALs0kT094118 for ; Mon, 10 Nov 2003 13:54:00 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAALrv84027719 for ; Mon, 10 Nov 2003 14:53:57 -0700 (MST) Message-ID: <3FB008F5.E811AFA5@INET-Calendar.net> Date: Mon, 10 Nov 2003 14:53:57 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: <004101c3a7cc$9917d9f0$6d9012c0@red.iplanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Satya Vempati wrote: > > I would like to suggest that everyone should make a conscious effort to > keep the discussion productive and not give way to acrimony. We need to > keep in mind that these archives have to be of some use to people who, > in future, browse them for information and answers. > > Most of the recent posts are nothing but invective and as such should > not posted to a technical public forum such as this one. I would like to suggest that whoever has control of this list some how suspend Bruce and what I believe to be his intentional misleading posts to this list. He repeatatly attempts to insite debate by posting false statements, inaccurate inforamtion and general trolling for trouble. From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:14:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16969 for ; Mon, 10 Nov 2003 17:14:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALtvkT094189 for ; Mon, 10 Nov 2003 13:55:57 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAALtv5H094188 for ietf-calendar-bks; Mon, 10 Nov 2003 13:55:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALtukT094177 for ; Mon, 10 Nov 2003 13:55:56 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAALtr84027726; Mon, 10 Nov 2003 14:55:53 -0700 (MST) Message-ID: <3FB00969.6DF17DBA@INET-Calendar.net> Date: Mon, 10 Nov 2003 14:55:53 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (VFREEBUSY auto reply) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark said on 11/10/2003 03:03:58 PM: > > So what - what he said is still true. Currently MANY systems > > PUBLISH freebusy, including the big vendor - please say you > > do not want to break them!!! > > In case you've never actually used their product, the model is that > the entire process is user centric, not some abstract calendar that > can be linked but to someone but not necessarily the contents of that > calendar. They use a single calendar model and their CUA pushes the > busytime out as necessary to a configured place. The "contacts" have > a URL where the client can go get busytime data for a particular > contact w/o doing any actual iTIP REQUEST/REPLY. So are you are > proposing we change CAP and iTIP to follow their direct access model > of busytime? I have see no text in CAP that stops auto create and auto reply of vfreebysy from working. And I have not seen even you dispute that the user busytime is not always the same as the calender busy time. Can you explain why you insist that all implementations that publish a user vfreebusy that is different that the calendar vfreebusy must break so that CAP fits your desired model? No I am repeating that it is the user busytime and not the calendar busytime has he has pointed out. And case you have not actuall used their product you may notice that the user can block out time that is not in the calender. Thus user busytime is not always the same as calendar busy time. In fact making the CS always auto create vfreebusy times is what changes the model. The existing CAP text allows the existing implementations and models that publish vfreebusy to continute to work. And CAP-12-newest does allow auto create to work and it does not break implementations that use publish to manually set the users vfreebusy time. Why do you keep insisting that if someone disagrees with you they do not understand? Looking through the archives I have found many instances of people talking about wanting to block out time that is not in the calendar. Example: There was (a long time ago) in the archives a debate to include include work schedules, which seems to have been droped specificaly because the vfreebusy time does not have to equal the calendar vfreebusy time. The work schedule components were ruled redundent as you could simply publish busy time that was not in your calendar. This is true of ITIP why do you insist that it can not be true in CAP? From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:25:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17420 for ; Mon, 10 Nov 2003 17:25:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAM4KkT094462 for ; Mon, 10 Nov 2003 14:04:20 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAM4Krw094461 for ietf-calendar-bks; Mon, 10 Nov 2003 14:04:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAM4JkT094456 for ; Mon, 10 Nov 2003 14:04:19 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: Mark Smith Cc: ietf-calendar@imc.org, Ned Freed , Ted Hardie Subject: Thick skinned chairs (Was Re: different calendar scales) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 17:00:23 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 05:04:05 PM, Serialize complete at 11/10/2003 05:04:05 PM Content-Type: multipart/alternative; boundary="=_alternative 00786DB885256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00786DB885256DDA_= Content-Type: text/plain; charset="US-ASCII" Mark said on 11/04/2003 07:45:19 PM MST: > > Or, better yet, get another, tougher skinned, working group > > chair. > > I would vote for that, I can not find ONE constructive comment > or item you have posted in the last year. I can not find that > you called conciseness on anything in the last year even when > no one objected to a proposal. I for one do not belive that being think skinned is a requirement of any IETF WG chair. While WG discussions can sometimes become heated there should never be a need for barbs to be constantly shot at chairs. Just as referees in boxing are not big muscle bound people in order to survive being in the ring and calling the match, chairs should not be expected to take any abuse just because their actions or opinions are not popuplar with one side or another. Im sure the ADs would agree with this assessment too. While its helpful for chairs to be more engaged at times, there should never be a need for them to be thick skinned to in order to handle abuse from unruly or quarrelsome WG participants. 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 00786DB885256DDA_= Content-Type: text/html; charset="US-ASCII"
Mark said on 11/04/2003 07:45:19 PM MST:
> > Or, better yet, get another, tougher skinned, working group
> > chair.
>
> I would vote for that, I can not find ONE constructive comment
> or item you have posted in the last year. I can not find that
> you called conciseness on anything in the last year even when
> no one objected to a proposal.

I for one do not belive that being think skinned is a requirement of any IETF WG chair.  While WG discussions can sometimes become heated there should never be a need for barbs to be constantly shot at chairs.  Just as referees in boxing are not big muscle bound people in order to survive being in the ring and calling the match, chairs should not be expected to take any abuse just because their actions or opinions are not popuplar with one side or another.  

Im sure the ADs would agree with this assessment too.  While its helpful for chairs to be more engaged at times, there should never be a need for them to be thick skinned to in order to handle abuse from unruly or quarrelsome WG participants.

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 00786DB885256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:26:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17486 for ; Mon, 10 Nov 2003 17:26:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAM05kT094297 for ; Mon, 10 Nov 2003 14:00:05 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAM05Np094296 for ietf-calendar-bks; Mon, 10 Nov 2003 14:00:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAM03kT094290 for ; Mon, 10 Nov 2003 14:00:03 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAAM01XK017332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 14:00:02 -0800 Message-ID: <3FB00A5C.8040604@Royer.com> Date: Mon, 10 Nov 2003 14:59:56 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: <004101c3a7cc$9917d9f0$6d9012c0@red.iplanet.com> In-Reply-To: <004101c3a7cc$9917d9f0$6d9012c0@red.iplanet.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090409080907010305070406" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090409080907010305070406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have updated my internet connection. Somehow I seem to be missing posts. They are in the archive, yet my server shows no record of them being sent to my SMTP server. Some posts are making it, others are not. Perhaps some are Cc'ing or Bcc'ing me and others are not. I may have to be copy/paste from the IMC server until I find the problem... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090409080907010305070406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTEwMjE1OTU2WjAjBgkqhkiG9w0BCQQxFgQUM172TMN8SH/nzvU/bymY AFDACW4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAq1nDIvWjCrQbesuZY8lsqCHM6h+vqYEemg2LxwaqatVW5cmTl4uAYIDLhAFCiTFk Q1JI02xcXiQsAUXYPrTZQJCyvkLiGBuIGc03rownvrrF4w58mThngAayzjbasdXIXjKQbign 6ciEypxRuH56mmRp3YbF4WN75yxbWPzvRcQOt/pp0Ce5KCXhaP6Yg5imeDiBWanK+gUZL7Cx QjvaPLy2w5Gvuo9o8jNTqm+KPuDF2n44+3saGUgClrnQvC8lJIdFGThhyms9Wa8/HY+q98V+ ayJn1g4UxxB6Htkp7czZW6bme2lp8JbsReuTG4HKg2O8uC3nb3M7C+mJEv9ZZAAAAAAAAA== --------------ms090409080907010305070406-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:28:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17741 for ; Mon, 10 Nov 2003 17:28:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAM94kT094623 for ; Mon, 10 Nov 2003 14:09:04 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAM94gU094622 for ietf-calendar-bks; Mon, 10 Nov 2003 14:09:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAM92kT094608 for ; Mon, 10 Nov 2003 14:09:02 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FB008F5.E811AFA5@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 10 Nov 2003 17:09:04 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/10/2003 05:09:05 PM, Serialize complete at 11/10/2003 05:09:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0079AE2485256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079AE2485256DDA_= Content-Type: text/plain; charset="US-ASCII" At the risk of incurring yet more grief, I'm going to second the comments of Satya. He said it well - we need to keep the comments to the issues. I think Bruce tries hard to read the emails and post accordingly. I believe he is not trying to "incite" debate - he's trying to get people to see the real issue. That's his speciality - knawing at an issue until we all see how it should be. And he is the first to say he understands an issue if he has been viewing it incorrectly or differently. And while my note may appear like I am endorsing Bruce, in reading back over his comments, it does indeed appear he is reading the posts. What, in fact, is surfacing, though, is that whenever he does choose to post, you go out of your way to comment on his statements. So, rather than asking Bruce to "suspend" his actions, it is rather better for the list to ask you to stay focused on the topic, and read the emails yourself. Please stop making the accusations and comments regarding Bruce's posts. The fact that Bruce is able to continue posting in spite of your comments is a point in his favor. Mark Smith Sent by: owner-ietf-calendar@mail.imc.org 11/10/2003 16:53 To ietf-calendar@imc.org cc Subject Re: Status of the CALSCH working group (Alarms/SEQUENCE) Satya Vempati wrote: > > I would like to suggest that everyone should make a conscious effort to > keep the discussion productive and not give way to acrimony. We need to > keep in mind that these archives have to be of some use to people who, > in future, browse them for information and answers. > > Most of the recent posts are nothing but invective and as such should > not posted to a technical public forum such as this one. I would like to suggest that whoever has control of this list some how suspend Bruce and what I believe to be his intentional misleading posts to this list. He repeatatly attempts to insite debate by posting false statements, inaccurate inforamtion and general trolling for trouble. --=_alternative 0079AE2485256DDA_= Content-Type: text/html; charset="US-ASCII"
At the risk of incurring yet more grief, I'm going to second the comments of Satya.  He said it well - we need to keep the comments to the issues.  

I think Bruce tries hard to read the emails and post accordingly.  I believe he is not trying to "incite" debate - he's trying to get people to see the real issue.  That's his speciality - knawing at an issue until we all see how it should be.  And he is the first to say he understands an issue if he has been viewing it incorrectly or differently.

And while my note may appear like I am endorsing Bruce,  in reading back over his comments, it does indeed appear he is reading the posts.  What, in fact, is surfacing, though, is that whenever he does choose to post, you go out of your way to comment on his statements.  So, rather than asking Bruce to "suspend" his actions, it is rather better for the list to ask you to stay focused on the topic, and read the emails yourself.  Please stop making the accusations and comments regarding Bruce's posts.  The fact that Bruce is able to continue posting in spite of your comments is a point in his favor.


Mark Smith <mark@inet-calendar.net>
Sent by: owner-ietf-calendar@mail.imc.org

11/10/2003 16:53

To
ietf-calendar@imc.org
cc
Subject
Re: Status of the CALSCH working group (Alarms/SEQUENCE)






Satya Vempati wrote:
>
> I would like to suggest that everyone should make a conscious effort to
> keep the discussion productive and not give way to acrimony. We need to
> keep in mind that these archives have to be of some use to people who,
> in future, browse them for information and answers.
>
> Most of the recent posts are nothing but invective and as such should
> not posted to a technical public forum such as this one.

I would like to suggest that whoever has control of this list
some how suspend Bruce and what I believe to be his intentional
misleading posts to this list. He repeatatly attempts to insite
debate by posting false statements, inaccurate inforamtion and
general trolling for trouble.
--=_alternative 0079AE2485256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:28:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17746 for ; Mon, 10 Nov 2003 17:28:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMAxkT094697 for ; Mon, 10 Nov 2003 14:10:59 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMAxNY094696 for ietf-calendar-bks; Mon, 10 Nov 2003 14:10:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMAvkT094690 for ; Mon, 10 Nov 2003 14:10:57 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: To: Bruce_Kahn@notesdev.ibm.com Cc: Ted Hardie , ietf-calendar@imc.org, Mark Smith , Ned Freed , owner-ietf-calendar@mail.imc.org Subject: Re: Thick skinned chairs (Was Re: different calendar scales) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 10 Nov 2003 17:10:59 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/10/2003 05:10:59 PM, Serialize complete at 11/10/2003 05:10:59 PM Content-Type: multipart/alternative; boundary="=_alternative 0079DB0385256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079DB0385256DDA_= Content-Type: text/plain; charset="US-ASCII" Thanks. Bruce_Kahn@notesdev.ibm.com Sent by: owner-ietf-calendar@mail.imc.org 11/10/2003 17:00 To Mark Smith cc ietf-calendar@imc.org, Ned Freed , Ted Hardie Subject Thick skinned chairs (Was Re: different calendar scales) Mark said on 11/04/2003 07:45:19 PM MST: > > Or, better yet, get another, tougher skinned, working group > > chair. > > I would vote for that, I can not find ONE constructive comment > or item you have posted in the last year. I can not find that > you called conciseness on anything in the last year even when > no one objected to a proposal. I for one do not belive that being think skinned is a requirement of any IETF WG chair. While WG discussions can sometimes become heated there should never be a need for barbs to be constantly shot at chairs. Just as referees in boxing are not big muscle bound people in order to survive being in the ring and calling the match, chairs should not be expected to take any abuse just because their actions or opinions are not popuplar with one side or another. Im sure the ADs would agree with this assessment too. While its helpful for chairs to be more engaged at times, there should never be a need for them to be thick skinned to in order to handle abuse from unruly or quarrelsome WG participants. 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 0079DB0385256DDA_= Content-Type: text/html; charset="US-ASCII"
Thanks.


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

11/10/2003 17:00

To
Mark Smith <mark@inet-calendar.net>
cc
ietf-calendar@imc.org, Ned Freed <ned.freed@mrochek.com>, Ted Hardie <hardie@qualcomm.com>
Subject
Thick skinned chairs (Was Re: different calendar scales)






Mark said on 11/04/2003 07:45:19 PM MST:
> > Or, better yet, get another, tougher skinned, working group
> > chair.
>
> I would vote for that, I can not find ONE constructive comment
> or item you have posted in the last year. I can not find that
> you called conciseness on anything in the last year even when
> no one objected to a proposal.

I for one do not belive that being think skinned is a requirement of any IETF WG chair.  While WG discussions can sometimes become heated there should never be a need for barbs to be constantly shot at chairs.  Just as referees in boxing are not big muscle bound people in order to survive being in the ring and calling the match, chairs should not be expected to take any abuse just because their actions or opinions are not popuplar with one side or another.  

Im sure the ADs would agree with this assessment too.  While its helpful for chairs to be more engaged at times, there should never be a need for them to be thick skinned to in order to handle abuse from unruly or quarrelsome WG participants.

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 0079DB0385256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:35:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18086 for ; Mon, 10 Nov 2003 17:35:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMF1kT094838 for ; Mon, 10 Nov 2003 14:15:01 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMF1gw094837 for ietf-calendar-bks; Mon, 10 Nov 2003 14:15:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMF0kT094832 for ; Mon, 10 Nov 2003 14:15:01 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FAFF08C.48C6A51B@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 10 Nov 2003 17:13:00 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/10/2003 05:15:03 PM, Serialize complete at 11/10/2003 05:15:03 PM Content-Type: multipart/alternative; boundary="=_alternative 0079953285256DDA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079953285256DDA_= Content-Type: text/plain; charset="US-ASCII" Mark blasted away on 11/10/2003 03:09:48 PM: > What does that have to do with the topic or the email asked or answered? > Nothing at all. > > Do you even follow the topics before posting? Normally I would not respond to this kind of trolling but Ill give you the benefit of the doubt and chalk this up to ignorance rather than malice. Nathaniel wrote: Alarms/SEQUENCE -- I remain confused: Can there be two identical objects in the same calendar? If not, we should clearly say so. to which Doug replied: You can and iCAL has no such restriction on any component including VALARMs. to which I pointed out that he was incorrect. iCalendar has at least 5 places where it says duplicates are to be treated as a single instance. I then pointed out that CAP also has text to this effect. So my reply was on topic just like the last time you said it wasnt. 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 0079953285256DDA_= Content-Type: text/html; charset="US-ASCII"
Mark blasted away on 11/10/2003 03:09:48 PM:
> What does that have to do with the topic or the email asked or answered?
> Nothing at all.
>
> Do you even follow the topics before posting?
Normally I would not respond to this kind of trolling but Ill give you the benefit of the doubt and chalk this up to ignorance rather than malice.  Nathaniel wrote:

Alarms/SEQUENCE -- I remain confused: Can there be two identical
objects in the same calendar? If not, we should clearly say so.

to which Doug replied:

You can and iCAL has no such restriction on any component including VALARMs.

to which I pointed out that he was incorrect.  iCalendar has at least 5 places where it says duplicates are to be treated as a single instance.  I then pointed out that CAP also has text to this effect.  So my reply was on topic just like the last time you said it wasnt.

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 0079953285256DDA_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:40:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18258 for ; Mon, 10 Nov 2003 17:40:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMNAkT095333 for ; Mon, 10 Nov 2003 14:23:10 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMNACi095332 for ietf-calendar-bks; Mon, 10 Nov 2003 14:23:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMN8kT095327 for ; Mon, 10 Nov 2003 14:23:08 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAAMN7XK017841 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 14:23:08 -0800 Message-ID: <3FB00FC5.5060307@Royer.com> Date: Mon, 10 Nov 2003 15:23:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (CALSCALE) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010506020505000108060705" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010506020505000108060705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (copy from archive) ------------------------------------------------------------------------ * To: "ietf-calendar@xxxxxxx " > * Subject: Re: Status of the CALSCH working group (CALSCALE) * From: Bruce_Kahn@xxxxxxxxxxxxxxxx * Date: Mon, 10 Nov 2003 10:41:18 -0500 * In-reply-to: <> * List-archive: * List-id: * List-unsubscribe: * Sender: owner-ietf-calendar@xxxxxxxxxxxx ------------------------------------------------------------------------ >>> CALSCALE -- I would like to either see us add a capability >> specification for calendar scales and a special error code for >> unsupported calendar scales, or I would like someone to convince me >> that the absence of such scales isn't really a problem for future >> extensions. What we have right now tells us that there might be other >> calendar scales, but doesn't really tell an implementation how to >> behave if it encounters one. >> >> iCAL can do a 'REQUEST-STATUS:3.1;Invalid property value;CALSCALE:foo' >> now and >> seems the correct choice for an unknown CALSCALE. > ... > In response to a CALSCALE:Foo property I would think the CS would send back a: > ...REQUEST-STATUS:3.13;Unsupported component or property found;CALSCALE\:Foo is unknown. > ...Unfortunately the new REQUEST-STATUS codes (Section 10.15 Response Codes) are > not well organized so its hard to tell exactly what should be sent back. ... (1) REQUEST-STATUS values '3.1' and '3.13' are defined in 2446 and not in CAP. (2) You have them backwards: In 2446 they are defined in section (3.6 Status Replies): 3.1 Invalid property value. Property name and value MAY be specified. 3.13 Unsupported component or property found. So, no not 3.13 as you state, but 3.1 (incorrect value) as sent in the original email is in fact correct. (3) The topic was do we add CALSCALE as a GET-CAPABILITY reply. I say it can wait until someone comes up with a new CALSCALE. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010506020505000108060705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTEwMjIyMzAxWjAjBgkqhkiG9w0BCQQxFgQUd65xEh6SdgOmQeaK35p8 c1HA3UEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAt9uelYT17KHMUmoT7iiU8c+Hx46wJUHnInKgfJS+3hvg3L7o2DFT0nhEVrtNPRD2 lqksE6dDTB+ghlbZX2msAvh67jSIyauQs73NbmViPOTH10ctyIosHM+y3DtjTu+jk1is07DA BKcAogJMkTDBjgeLtx9zyPPgK/k4d5rgh1fn7HBYv/MTs6V6ohvaU6dGCr4qpMjbFoK2DtA0 P8GhypU7PHdJpCAgyV1U84qCCDOmuz4PQmuAkAmezoeWkfRF9nhepq9gZA12e+KcG2MR8OCs xdUxiDTNhyeQUL/eMrbSeChurI2CUPXxqeArciejcRseoxOl9zwDkStBq/9tnAAAAAAAAA== --------------ms010506020505000108060705-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:45:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18697 for ; Mon, 10 Nov 2003 17:45:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMT5kT095533 for ; Mon, 10 Nov 2003 14:29:05 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMT5As095532 for ietf-calendar-bks; Mon, 10 Nov 2003 14:29:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.localdomain (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMT4kT095527 for ; Mon, 10 Nov 2003 14:29:04 -0800 (PST) (envelope-from capps@osafoundation.org) Received: from osafoundation.org (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hAAMSndB003905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2003 14:28:50 -0800 Message-ID: <3FB01173.2030305@osafoundation.org> Date: Mon, 10 Nov 2003 14:30:11 -0800 From: Katie Capps Parlante User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathaniel Borenstein CC: ietf-calendar@imc.org Subject: Re: Minneapolis Meeting References: <8FC6B77E-13A2-11D8-84C6-000A9571873E@guppylake.com> In-Reply-To: <8FC6B77E-13A2-11D8-84C6-000A9571873E@guppylake.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello all, I'm a lurker who will not be in Minneapolis, but would be interested in participating (well, ok, mostly lurking) via Jabber. I'm an engineer working at OSAF (http://www.osafoundation.org/). We're going to be writing a pim that does calendaring, and are planning on working and playing well with the ietf calendaring standards. We haven't yet had anything interesting to contribute to this list, but just to let you know who is lurking. Cheers, Katie Nathaniel Borenstein wrote: > This does lead to an obvious question: Who is showing up? At this point > I'm not aware of anyone other than myself who will actually be there.... > It could be a very short meeting! -- Nathaniel > > On Monday, November 10, 2003, at 11:41 AM, pregen@egenconsulting.com wrote: > > > Because of a sudden death in the family, I have had to cancel my > trip to Minneapolis. I have asked Nathaniel Borenstein to chair the > Tuesday CALSCH session. He has graciously accepted and if anyone > on the list (active or lurking) will be in that session, he will > need someone to take minutes or enter data into Jabber. I would > appreciate any volunteers that show up. 8-) > > Again, thanks to everyone for their support of this group. Sorry I > won't be there. > > Pat > > From owner-ietf-calendar@mail.imc.org Mon Nov 10 17:49:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18833 for ; Mon, 10 Nov 2003 17:49:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMU6kT095565 for ; Mon, 10 Nov 2003 14:30:06 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMU6wr095564 for ietf-calendar-bks; Mon, 10 Nov 2003 14:30:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMU3kT095558 for ; Mon, 10 Nov 2003 14:30:04 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAAMU0XK017905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 14:30:02 -0800 Message-ID: <3FB01163.9050908@Royer.com> Date: Mon, 10 Nov 2003 15:29:55 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Status of the CALSCH working group (CALID vs CU time) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080200040700000407030300" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080200040700000407030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------ * To: "ietf-calendar@xxxxxxx " > * Subject: Re: Status of the CALSCH working group * From: Bruce_Kahn@xxxxxxxxxxxxxxxx * Date: Mon, 10 Nov 2003 12:02:28 -0500 * In-reply-to: <> * List-archive: * List-id: * List-unsubscribe: * Sender: owner-ietf-calendar@xxxxxxxxxxxx ------------------------------------------------------------------------ >> Because some want and expect the CU (user) VFREEBUSY and others want the >> CALID (calendar) VFREEBUSY. Currently the iTIP method gets the CU VFREEBUSY >> that just might be the same as the CALID VFREEBUSY. > We have never drawn a distinction between a CUs availability or a calendars before. Are you saying you have > some proposal in mind for drawing a distinction? Something like hierarchical calendars with busytime / content > rollup or "calendar bundling"? Please say no... If I spend the time and go find the instances where we have talked about it, will you change your mind? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080200040700000407030300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTEwMjIyOTU1WjAjBgkqhkiG9w0BCQQxFgQUf5kBaTCjCrEJ3iFxuPKb xvshT+0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAKIz6OdKa0Oo4Qlne5En6ONkx18dm7XTW8fqJxhx04w5HO5vBWRkNlDp7NWHr6FP+ +pJe5ye205VNs/2MmJ/ljNjBd2xPfaN4FK+k2sM5IX7A6QAvlor3orSuIC3CtDm3mxFMaXh0 oCWMBgBbHAEHm/Gcn7sHjv9lWHPd215/Wi8oTCWfijgI4nn4rhwP7geuynmJQl1cuoDanOWe S4rS2Fyj5smgDMl8tQDQlunQMORIplGPhPxPpz5mHQjYHEz20z+0OnJVgWEuGZLv9vZTmCSE m6Dqo7Jib5Km7fCZGhdztwZPs6IcXvv9EeWHLqfRaxGmX4zhd9HJZvHR/Qk5WQAAAAAAAA== --------------ms080200040700000407030300-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 18:07:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20016 for ; Mon, 10 Nov 2003 18:07:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMj9kT096521 for ; Mon, 10 Nov 2003 14:45:09 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAAMj9ci096520 for ietf-calendar-bks; Mon, 10 Nov 2003 14:45:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMj7kT096509 for ; Mon, 10 Nov 2003 14:45:08 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAAMj584027818 for ; Mon, 10 Nov 2003 15:45:05 -0700 (MST) Message-ID: <3FB014F1.E0F61635@INET-Calendar.net> Date: Mon, 10 Nov 2003 15:45:05 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark blasted away on 11/10/2003 03:09:48 PM: > > What does that have to do with the topic or the email asked or > answered? > > Nothing at all. > > > > Do you even follow the topics before posting? > > Normally I would not respond to this kind of trolling but Ill give you > the benefit of the doubt and chalk this up to ignorance rather than > malice. Nathaniel wrote: > > Alarms/SEQUENCE -- I remain confused: Can there be two identical > objects in the same calendar? If not, we should clearly say so. > > to which Doug replied: > > You can and iCAL has no such restriction on any component including > VALARMs. > > to which I pointed out that he was incorrect. iCalendar has at least > 5 places where it says duplicates are to be treated as a single > instance. I then pointed out that CAP also has text to this effect. > So my reply was on topic just like the last time you said it wasnt. Bull, a valarm is not the same thing as a vevent instance, and criplling the comments posted to imply they mean instances of a vevent is just more trolling. And you still refues to stick to the point. How do you fix one? From owner-ietf-calendar@mail.imc.org Mon Nov 10 19:03:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24594 for ; Mon, 10 Nov 2003 19:03:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAANhhkT098677 for ; Mon, 10 Nov 2003 15:43:43 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAANhhT5098676 for ietf-calendar-bks; Mon, 10 Nov 2003 15:43:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAANhfkT098671 for ; Mon, 10 Nov 2003 15:43:42 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAANheXK019052 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 15:43:41 -0800 Message-ID: <3FB022A7.4060804@Royer.com> Date: Mon, 10 Nov 2003 16:43:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Thick skinned chairs (Was Re: different calendar scales) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040401020400080301020605" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040401020400080301020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark said on 11/04/2003 07:45:19 PM MST: > > > Or, better yet, get another, tougher skinned, working group > > > chair. > > > > I would vote for that, I can not find ONE constructive comment > > or item you have posted in the last year. I can not find that > > you called conciseness on anything in the last year even when > > no one objected to a proposal. > > I for one do not belive that being think skinned is a requirement of > any IETF WG chair. While WG discussions can sometimes become heated > there should never be a need for barbs to be constantly shot at > chairs. Just as referees in boxing are not big muscle bound people in > order to survive being in the ring and calling the match, chairs > should not be expected to take any abuse just because their actions or > opinions are not popuplar with one side or another. I do strongly wish that Pat were more proactive on this list. And I do agree with Bruce that she has been a great aid to this list. > > Im sure the ADs would agree with this assessment too. While its > helpful for chairs to be more engaged at times, there should never be > a need for them to be thick skinned to in order to handle abuse from > unruly or quarrelsome WG participants. I feel you also fall into that category. You have posted several items that had already been fixed in CAP then tended to imply that no one was listening or responding to you. And your mode seems to be an expectation that I respond to you each and every time you ask a question even when it is a loaded or an out of date question. I nor this WG report to Bruce as we are all volunteers on this list with our own jobs. Although I do not like the way Mark formulates his comments, they tend to be accurate. You do tend to post about already fixed items or change the contents to make your post true AND unrelated to the topic. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040401020400080301020605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTEwMjM0MzM1WjAjBgkqhkiG9w0BCQQxFgQU91cY4Pi4Sr+ws4xJwCm6 /y3BLy4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAT564aMYjPGRnp59eFMwULWlr5MlE6V4AL1td9adxPYFJI3GA6SvwgRJOLwlR+irV q5LeLsJ/7ZnMDSIDbXr1rbp0bTrFVwjyNro1vkt9WbQ62wn+3d1tLlbamVeDm29yASv3Jba0 ihu3aaOuNoTjDgjoIE999KggyYeuyG/xV59b2MviN7KZ7miVxpTAGNjUDf7tLASRR8AJbUxV RWyM/Gnrusx1R+yRqe4VOt01HAqZ3PNEzt27H7evqNTMMaPipS/Li1mexNDoF4b0BUNQBdAu pCD7Nr3lWdavQ5Z0eL0H0WVG2G+504mfdBvzyP8hTT4hNLd2BSKfQ5dsU2P6UwAAAAAAAA== --------------ms040401020400080301020605-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 19:59:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26644 for ; Mon, 10 Nov 2003 19:59:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB0apkT001532 for ; Mon, 10 Nov 2003 16:36:51 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB0apXB001531 for ietf-calendar-bks; Mon, 10 Nov 2003 16:36:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB0aokT001526 for ; Mon, 10 Nov 2003 16:36:50 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAB0akXK019768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 16:36:47 -0800 Message-ID: <3FB02F19.2060109@Royer.com> Date: Mon, 10 Nov 2003 17:36:41 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-e: Changing REQUEST-STATUS References: <3FAFECED.4090905@Royer.com> In-Reply-To: <3FAFECED.4090905@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020704000102070305020001" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020704000102070305020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think it is supposed to be: statcode ";" [ statdesc ] ";" [extdata] Doug Royer wrote: > > I remember at or before -00 time, we had a problem with the iCAL > version of REQUEST-STATUS and how it effected some error handling. > Fixing REQUEST-STATUS was one of the todo items for CAP. > Still looking through archives... > > I am guessing it was just fixed incorrectly and no one noticed since -08. > > As in -07 it was incorrectly: > > statcode [";" statdesc [";" extdata]] > > I am guessing the incorrect ABNF got incorrectly fixed. > > Bruce_Kahn@notesdev.ibm.com wrote: > >> >> In looking up something related to CALSCALE I noticed that CAP-12-e >> makes an unmentioned change to iCalendars REQUEST-STATUS property. >> This change is NOT good NOR is it necessary. > > > If you would have looked closer it was not mentioned in -12-e becaues > it did not > change in -12-e. > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020704000102070305020001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTExMDAzNjQxWjAjBgkqhkiG9w0BCQQxFgQUvkz+DLCIqr88ff31RNK2 PPEcYZ8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAGbCz1ohM/MJakNTLlDHDyfIW7mKt0T3GSI08L1ngVXHcgNqiRFA2UMdNASusCSUz RLY6+9zNJcmtwRZm3DVbSUKgwm91fbP0sDpwogBVJZ2vb1PYMJAUKU0AtpBjSSLH82T5FWcD F1p2BSAyTAZZhBpwzGofgL+fsDwIf2/NkeXg6nRMBMug8wVFZW3kWQElAy+kDp6t+mzWxyip qATEj2I6aV5Xa+567lGLnWG5UZrJfcX1wvTPbL8p6r8oS2ijcBT1VqxqPIRVm0Li7cW5v8r9 R2H3B2e6pm7Im98LUFTXNJXHugXmYtV4LAHfSob9f44CBbXpmd8hsXF3ni5gtAAAAAAAAA== --------------ms020704000102070305020001-- From owner-ietf-calendar@mail.imc.org Mon Nov 10 20:15:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27039 for ; Mon, 10 Nov 2003 20:15:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB0wlkT002367 for ; Mon, 10 Nov 2003 16:58:47 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB0wlxZ002366 for ietf-calendar-bks; Mon, 10 Nov 2003 16:58:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB0wkkT002361 for ; Mon, 10 Nov 2003 16:58:46 -0800 (PST) (envelope-from gsbarnes@u.washington.edu) Received: from mead11.u.washington.edu (mead11.u.washington.edu [140.142.12.175]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAB0whaZ025099 for ; Mon, 10 Nov 2003 16:58:48 -0800 Received: from localhost (gsbarnes@localhost) by mead11.u.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAB0whki954432 for ; Mon, 10 Nov 2003 16:58:43 -0800 Date: Mon, 10 Nov 2003 16:58:43 -0800 (PST) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 10 Nov 2003 Bruce_Kahn@notesdev.ibm.com wrote: > I have yet to hear any good justification for allowing "identical but > separate" VALARMs that match any practical view of things. Despite Dougs > and Marks claim, the only reason to have SEQUENCE (or ALARMID) on VALARMs > is for this rare usage case that currently noone actually has nor models > anyones actual behaviour or needs. Id like to apply KISS to this and move > CAP along... (Just like we disallow multiple copies of the same booked > entry, the same should go for alarms). Two responses: 1) To move CAP along, I think we have to concede that the question of unique ids for VALARMs was already considered, and unique ids were considered good by almost everyone. From the archive, it appears this was most heavily discussed November 2001-January 2002, and everyone seemed to agree that alarmids of some sort were useful. For example, from: Steve Mansour wrote: }I agree. I think it is far simpler to just always add the alarmid. }I'll make the update. If anyone has any objections let's go through it }on the list. (we can always pull it out later if someone comes up with }a good reason for NOT having an alarm id). [Needless to say, no one had any objections and no one came up with such a reason that I could see.] 2) As for what's the use of duplicate alarms, what if I want to send myself 20 e-mail messages to make sure I get the hint? Or have 5 windows opening with blinking text? Who are we to say what a user might think is useful? Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Mon Nov 10 21:02:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29408 for ; Mon, 10 Nov 2003 21:02:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB1kQkT004435 for ; Mon, 10 Nov 2003 17:46:26 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB1kQHj004434 for ietf-calendar-bks; Mon, 10 Nov 2003 17:46:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB1kOkT004424 for ; Mon, 10 Nov 2003 17:46:24 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hAB1kM84028039 for ; Mon, 10 Nov 2003 18:46:22 -0700 (MST) Message-ID: <3FB03F6E.BE838A45@INET-Calendar.net> Date: Mon, 10 Nov 2003 18:46:22 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "G. Barnes" wrote: > > On Mon, 10 Nov 2003 Bruce_Kahn@notesdev.ibm.com wrote: > > > I have yet to hear any good justification for allowing "identical but > > separate" VALARMs that match any practical view of things. Despite Dougs > > and Marks claim, the only reason to have SEQUENCE (or ALARMID) on VALARMs > > is for this rare usage case that currently noone actually has nor models > > anyones actual behaviour or needs. Id like to apply KISS to this and move > > CAP along... (Just like we disallow multiple copies of the same booked > > entry, the same should go for alarms). ICAL disallows two identical vevents because the uid distinguishes them. And ICAL defines if they have the same uid, then they are the same object in a possible different state or time. ICAL does not disallow vevents that would be identical except for the unique identifier. > 2) As for what's the use of duplicate alarms, what if I want to send > myself 20 e-mail messages to make sure I get the hint? Or have 5 windows > opening with blinking text? Who are we to say what a user might think is > useful? Again the only thing I see is the fix the oops alarms which I have done more than once. From owner-ietf-calendar@mail.imc.org Mon Nov 10 23:27:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04745 for ; Mon, 10 Nov 2003 23:27:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB4D5kT010864 for ; Mon, 10 Nov 2003 20:13:05 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB4D5sm010863 for ietf-calendar-bks; Mon, 10 Nov 2003 20:13:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB4D2kT010856 for ; Mon, 10 Nov 2003 20:13:03 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FB022A7.4060804@Royer.com> To: ietf-calendar@imc.org Subject: Re: Thick skinned chairs (Was Re: different calendar scales) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Mon, 10 Nov 2003 23:13:04 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/10/2003 11:13:06 PM, Serialize complete at 11/10/2003 11:13:06 PM Content-Type: multipart/alternative; boundary="=_alternative 0016EA8285256DDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0016EA8285256DDB_= Content-Type: text/plain; charset="US-ASCII" Ok. That's fair and I agree. Doug Royer wrote: >> I do strongly wish that Pat were more proactive on this list. --=_alternative 0016EA8285256DDB_= Content-Type: text/html; charset="US-ASCII"
Ok.  That's fair and I agree.  

Doug Royer wrote:
>> I do strongly wish that Pat were more proactive on this list. --=_alternative 0016EA8285256DDB_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 09:49:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02786 for ; Tue, 11 Nov 2003 09:49:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABESbkT002835 for ; Tue, 11 Nov 2003 06:28:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABESbZA002834 for ietf-calendar-bks; Tue, 11 Nov 2003 06:28:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABESakT002825 for ; Tue, 11 Nov 2003 06:28:36 -0800 (PST) (envelope-from bobmah@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id hABESVR6029205; Tue, 11 Nov 2003 09:28:31 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id hABESTSp022052; Tue, 11 Nov 2003 09:28:29 -0500 (EST) Received: from [66.93.190.32] (dsl093-190-034.nyc2.dsl.speakeasy.net [66.93.190.34]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id hABESL4f027087; Tue, 11 Nov 2003 09:28:27 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@PO12.MIT.EDU Message-Id: In-Reply-To: References: Date: Tue, 11 Nov 2003 09:28:20 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Re: Thick skinned chairs (Was Re: different calendar scales) Cc: Mark Smith , Ned Freed , Ted Hardie , Bruce_Kahn@notesdev.ibm.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Part of the problem, for me at least, is that my work responsibilities have moved me solidly away from calendaring. My day job, network security in a 50k-host network without a firewall, has moved to remove anything like "free time" from my life over the last two years. (Microsoft owes me "one peaceful summer", at bare minimum) I was ready to step away at just the time that Pat lost her travel funding... Since MIT would continue to send me to physical meetings, I've tried to be available for the in-person chair needs, and have hoped that WG members and Pat's free cycles would be enough to carry the work forward. The situation has been difficult, and to the extent possible, Pat and I have certainly tried to at least keep the WG alive, so that what work and solutions that are possible will have a chance to move forward. As the needs of the WG for hands-on intervention have grown, our fragile availability has been a problem. It would appear that we are at a real turning point at present, between WG debate, problem complexity, general intellectual fatigue, and chair availability. We would certainly all like for productive work to move forward, but I think we need some increased understanding across the board, and a renewed energy and focus on the work, if this effort is to survive. To some extent, this may require some compromise and a more mindful exercise of politeness among list members. We all want useful calendaring standards deployed and used, and we need to remember that long debate and angry words are a strong threat to that hope... -Bob From owner-ietf-calendar@mail.imc.org Tue Nov 11 10:20:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05173 for ; Tue, 11 Nov 2003 10:20:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABF1PkT004496 for ; Tue, 11 Nov 2003 07:01:25 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABF1Pds004495 for ietf-calendar-bks; Tue, 11 Nov 2003 07:01:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABF1NkT004484 for ; Tue, 11 Nov 2003 07:01:23 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: To: Bob Mahoney Cc: Bruce_Kahn@notesdev.ibm.com, Ted Hardie , ietf-calendar@imc.org, Mark Smith , Ned Freed , owner-ietf-calendar@mail.imc.org Subject: Re: Thick skinned chairs (Was Re: different calendar scales) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 11 Nov 2003 10:01:22 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/11/2003 10:01:24 AM, Serialize complete at 11/11/2003 10:01:24 AM Content-Type: multipart/alternative; boundary="=_alternative 0052861185256DDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0052861185256DDB_= Content-Type: text/plain; charset="US-ASCII" ditto. Bob Mahoney Sent by: owner-ietf-calendar@mail.imc.org 11/11/2003 09:28 To ietf-calendar@imc.org cc Mark Smith , Ned Freed , Ted Hardie , Bruce_Kahn@notesdev.ibm.com Subject Re: Thick skinned chairs (Was Re: different calendar scales) Part of the problem, for me at least, is that my work responsibilities have moved me solidly away from calendaring. My day job, network security in a 50k-host network without a firewall, has moved to remove anything like "free time" from my life over the last two years. (Microsoft owes me "one peaceful summer", at bare minimum) I was ready to step away at just the time that Pat lost her travel funding... Since MIT would continue to send me to physical meetings, I've tried to be available for the in-person chair needs, and have hoped that WG members and Pat's free cycles would be enough to carry the work forward. The situation has been difficult, and to the extent possible, Pat and I have certainly tried to at least keep the WG alive, so that what work and solutions that are possible will have a chance to move forward. As the needs of the WG for hands-on intervention have grown, our fragile availability has been a problem. It would appear that we are at a real turning point at present, between WG debate, problem complexity, general intellectual fatigue, and chair availability. We would certainly all like for productive work to move forward, but I think we need some increased understanding across the board, and a renewed energy and focus on the work, if this effort is to survive. To some extent, this may require some compromise and a more mindful exercise of politeness among list members. We all want useful calendaring standards deployed and used, and we need to remember that long debate and angry words are a strong threat to that hope... -Bob --=_alternative 0052861185256DDB_= Content-Type: text/html; charset="US-ASCII"
ditto.


Bob Mahoney <bobmah@MIT.EDU>
Sent by: owner-ietf-calendar@mail.imc.org

11/11/2003 09:28

To
ietf-calendar@imc.org
cc
Mark Smith <mark@inet-calendar.net>, Ned Freed <ned.freed@mrochek.com>, Ted Hardie <hardie@qualcomm.com>, Bruce_Kahn@notesdev.ibm.com
Subject
Re: Thick skinned chairs (Was Re: different calendar scales)






Part of the problem, for me at least, is that my work responsibilities have moved me solidly away from calendaring.  My day job, network security in a 50k-host network without a firewall, has moved to remove anything like "free time" from my life over the last two years.   (Microsoft owes me "one peaceful summer", at bare minimum)

I was ready to step away at just the time that Pat lost her travel funding...  Since MIT would continue to send me to physical meetings, I've tried to be available for the in-person chair needs, and have hoped that WG members and Pat's free cycles would be enough to carry the work forward.  

The situation has been difficult, and to the extent possible, Pat and I have certainly tried to at least keep the WG alive, so that what work and solutions that are possible will have a chance to move forward.  As the needs of the WG for hands-on intervention have grown, our fragile availability has been a problem.

It would appear that we are at a real turning point at present, between WG debate, problem complexity, general intellectual fatigue, and chair availability.  We would certainly all like for productive work to move forward, but I think we need some increased understanding across the board, and a renewed energy and focus on the work, if this effort is to survive.  To some extent, this may require some compromise and a more mindful exercise of politeness among list members.   We all want useful calendaring standards deployed and used, and we need to remember that long debate and angry words are a strong threat to that hope...

-Bob
--=_alternative 0052861185256DDB_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 10:29:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05819 for ; Tue, 11 Nov 2003 10:29:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABFD4kT005029 for ; Tue, 11 Nov 2003 07:13:04 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABFD4Y3005028 for ietf-calendar-bks; Tue, 11 Nov 2003 07:13:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABFD3kT005023 for ; Tue, 11 Nov 2003 07:13:03 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hABFD1XK029614 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 11 Nov 2003 07:13:02 -0800 Message-ID: <3FB0FC78.5060703@Royer.com> Date: Tue, 11 Nov 2003 08:12:56 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Calsch / Jabber down Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040201050808070002030306" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040201050808070002030306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jabber will not let me post, but I can read. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040201050808070002030306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTExMTUxMjU2WjAjBgkqhkiG9w0BCQQxFgQUb3A6GUzvfM1IxRqHRguV RjMmnLIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAhLpiIEAMOsneCRc42E3KwVYRcf9AWVj+ASGCLkzkx4A+QrrQYmLb+CzLHp3iRsCy XYxunlXF20hPO/jABA/ZMaqUWzLmWFZHIyeNVYEm5YObc8v6DG98KO5O7KANaSThSbDIqJxR 11Eclk2zhgNBH/1B8GyleUXqZ/NrmAeAObq99Wd2L9NqJYnsoXEYJgauOMOTgMS3V5siDdy5 E+HZyqg1WL0wEJjBMG9iWzkcxLvSpRmymc5Iix1GNRQJ78sMOk0JcRA37GBIy3QYkgilKGlq XRvWSCnVl0/o9P44mckSiDIZMQajx9NQUFaVEBnL6y9tsgsffXIyLGlkACeq/QAAAAAAAA== --------------ms040201050808070002030306-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 11:04:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07352 for ; Tue, 11 Nov 2003 11:04:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABFiSkT006721 for ; Tue, 11 Nov 2003 07:44:28 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABFiSev006720 for ietf-calendar-bks; Tue, 11 Nov 2003 07:44:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABFiRkT006714 for ; Tue, 11 Nov 2003 07:44:27 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FB022A7.4060804@Royer.com> To: ietf-calendar@imc.org Subject: Re: Thick skinned chairs (Was Re: different calendar scales) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 11 Nov 2003 10:44:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/11/2003 10:44:14 AM, Serialize complete at 11/11/2003 10:44:14 AM Content-Type: multipart/alternative; boundary="=_alternative 0055FA8C85256DDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055FA8C85256DDB_= Content-Type: text/plain; charset="US-ASCII" Doug chimed in on 11/10/2003 06:43:35 PM: > You do tend to post about already fixed items or change the > contents to make your post true AND unrelated to the topic. Actually, when Mark has jumped in and said my replys were not relevant they have been as I have shown and as John confirmed the 1st time. 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 0055FA8C85256DDB_= Content-Type: text/html; charset="US-ASCII"
Doug chimed in on 11/10/2003 06:43:35 PM:
>                 You do tend to post about already fixed items or change the
> contents to make your post true AND unrelated to the topic.
Actually, when Mark has jumped in and said my replys were not relevant they have been as I have shown and as John confirmed the 1st time.

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 0055FA8C85256DDB_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 11:19:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07860 for ; Tue, 11 Nov 2003 11:19:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABG0JkT007155 for ; Tue, 11 Nov 2003 08:00:19 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABG0J7e007154 for ietf-calendar-bks; Tue, 11 Nov 2003 08:00:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABG0IkT007149 for ; Tue, 11 Nov 2003 08:00:18 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FB022A7.4060804@Royer.com> To: ietf-calendar@imc.org Subject: Re: Thick skinned chairs (Was Re: different calendar scales) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 11 Nov 2003 11:00:11 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/11/2003 11:00:04 AM, Serialize complete at 11/11/2003 11:00:04 AM Content-Type: multipart/alternative; boundary="=_alternative 00576F6F85256DDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00576F6F85256DDB_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/10/2003 06:43:35 PM: > > Im sure the ADs would agree with this assessment too. While its > > helpful for chairs to be more engaged at times, there should never be > > a need for them to be thick skinned to in order to handle abuse from > > unruly or quarrelsome WG participants. > > I feel you also fall into that category. Thats your perogative. However, dont confuse persistance on issues with abuse of chairs when they disagree with you. I have NOT verbally abused or acosted the chairs like others here. > You have posted several items > that had already > been fixed in CAP then tended to imply that no one was listening or > responding to you. Both of us have been in some heated discussions here as most everyone can tell. If the questions asked/rasied have been answered then it should just be a simple matter to refer to the proper WG thread where it was covered and resolved. That is, if it was actually discussed and resolved. If not, asking again is still a valid option. Whenever I missed something and it was pointed out to me, I acknowledged that publically (ie: searching for busytime text in 10.12.1). However that does not mean questions about it cannot be raised. Especially since the design and text were the product of one person and not the WG at large. > And your mode seems to be an expectation that I respond to you each and > every time you > ask a question even when it is a loaded or an out of date question. I > nor this WG report > to Bruce as we are all volunteers on this list with our own jobs. As Editor you should be able to answer questions about content of the draft, especially the intent of text. If you are unable or unwilling then we should get a co-editor or replacement editor who can or is at least willing to try. 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 00576F6F85256DDB_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/10/2003 06:43:35 PM:
> > Im sure the ADs would agree with this assessment too.  While its
> > helpful for chairs to be more engaged at times, there should never be
> > a need for them to be thick skinned to in order to handle abuse from
> > unruly or quarrelsome WG participants.
>
> I feel you also fall into that category.

Thats your perogative.  However, dont confuse persistance on issues with abuse of chairs when they disagree with you.  I have NOT verbally abused or acosted the chairs like others here.

>                                          You have posted several items
> that had already
> been fixed in CAP then tended to imply that no one was listening or
> responding to you.

Both of us have been in some heated discussions here as most everyone can tell.  If the questions asked/rasied have been answered then it should just be a simple matter to refer to the proper WG thread where it was covered and resolved.  That is, if it was actually discussed and resolved.  If not, asking again is still a valid option.

Whenever I missed something and it was pointed out to me, I acknowledged that publically (ie: searching for busytime text in 10.12.1).  However that does not mean questions about it cannot be raised.  Especially since the design and text were the product of one person and not the WG at large.

> And your mode seems to be an expectation that I respond to you each and
> every time you
> ask a question even when it is a loaded or an out of date question. I
> nor this WG report
> to Bruce as we are all volunteers on this list with our own jobs.
As Editor you should be able to answer questions about content of the draft, especially the intent of text.  If you are unable or unwilling then we should get a co-editor or replacement editor who can or is at least willing to try.  

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 00576F6F85256DDB_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 11:57:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09863 for ; Tue, 11 Nov 2003 11:57:53 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGfqkT009406 for ; Tue, 11 Nov 2003 08:41:52 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABGfqrq009405 for ietf-calendar-bks; Tue, 11 Nov 2003 08:41:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGfpkT009398 for ; Tue, 11 Nov 2003 08:41:51 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hABGfl84029111 for ; Tue, 11 Nov 2003 09:41:47 -0700 (MST) Message-ID: <3FB1114B.F3742D86@INET-Calendar.net> Date: Tue, 11 Nov 2003 09:41:47 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Thick skinned chairs (Was Re: different calendar scales) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 11/10/2003 06:43:35 PM: > > > Im sure the ADs would agree with this assessment too. While its > > > helpful for chairs to be more engaged at times, there should never > be > > > a need for them to be thick skinned to in order to handle abuse > from > > > unruly or quarrelsome WG participants. > > > > I feel you also fall into that category. > > Thats your perogative. However, dont confuse persistance on issues > with abuse of chairs when they disagree with you. I have NOT verbally > abused or acosted the chairs like others here. You post misleading posts about them, the history of the topic, or conveniently neglect to post that there were are majority that disagreed with you, how is that different and not abuse? Your posts continue to fail to be realistic with respect with what was posted. From owner-ietf-calendar@mail.imc.org Tue Nov 11 11:58:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09903 for ; Tue, 11 Nov 2003 11:58:19 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGcikT009253 for ; Tue, 11 Nov 2003 08:38:44 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABGcibW009252 for ietf-calendar-bks; Tue, 11 Nov 2003 08:38:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGchkT009237 for ; Tue, 11 Nov 2003 08:38:43 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hABGcd84029104 for ; Tue, 11 Nov 2003 09:38:39 -0700 (MST) Message-ID: <3FB1108F.25C79513@INET-Calendar.net> Date: Tue, 11 Nov 2003 09:38:39 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Thick skinned chairs (Was Re: different calendar scales) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug chimed in on 11/10/2003 06:43:35 PM: > > You do tend to post about already fixed items or > change the > > contents to make your post true AND unrelated to the topic. > > Actually, when Mark has jumped in and said my replys were not relevant > they have been as I have shown and as John confirmed the 1st time. Three people in the last few days have declared your posts as not accurate with respect to the archives, history, or topic. From owner-ietf-calendar@mail.imc.org Tue Nov 11 12:02:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10115 for ; Tue, 11 Nov 2003 12:02:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGkfkT009790 for ; Tue, 11 Nov 2003 08:46:41 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABGkeUF009789 for ietf-calendar-bks; Tue, 11 Nov 2003 08:46:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGkckT009784 for ; Tue, 11 Nov 2003 08:46:39 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hABGkcXK030969 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 11 Nov 2003 08:46:38 -0800 Message-ID: <3FB11268.2030000@Royer.com> Date: Tue, 11 Nov 2003 09:46:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Thick skinned chairs (Was Re: different calendar scales) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090109050309040301010607" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090109050309040301010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > And your mode seems to be an expectation that I respond to you each and > > every time you > > ask a question even when it is a loaded or an out of date question. I > > nor this WG report > > to Bruce as we are all volunteers on this list with our own jobs. > > As Editor you should be able to answer questions about content of the > draft, especially the intent of text. If you are unable or unwilling > then we should get a co-editor or replacement editor who can or is at > least willing to try. Yes, and I do. I just will not answer the same question the 2nd...many times. Read the archives first for the answers when you can not remember the reply. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090109050309040301010607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTExMTY0NjMyWjAjBgkqhkiG9w0BCQQxFgQUrG8lcIPKXeO1lLiCp+Py FrRF2J8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAZSZ0WJZEsOZEDOmZz5aQ/jDazTyxBcszrxpYlfdYS3SdARQ6EhA8X8sZ+150GIOk rdkfeWYw041utiOETH+sEs2eXj/i0MpERo9gyw0EZbFzaiawHURmmaCKIjdGpkPKFwyw7qO2 zKdZjWP75v4bh5+6Lmqf7DWS7INpCWMledN/1QgL5lPktmZMwBx86fs81W5zEHfwT39ykt4S BFOwu8naxdAcWBwF4N3HgR1q2CSGBDcnwKKRLM4XWkh6avLW7AVFdkLXvdbh19qVU9mYOOFh 3yDBTtoOeTDZRT9b/9x+MKuODOBNV1AmqGaiN0DGJY29kb9rA1IUkA0z4lVXbgAAAAAAAA== --------------ms090109050309040301010607-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 13:06:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13854 for ; Tue, 11 Nov 2003 13:06:29 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABHpAkT012764 for ; Tue, 11 Nov 2003 09:51:10 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABHpA1N012763 for ietf-calendar-bks; Tue, 11 Nov 2003 09:51:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABHp7kT012755 for ; Tue, 11 Nov 2003 09:51:10 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FB03F6E.BE838A45@INET-Calendar.net> To: Mark Smith Cc: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 11 Nov 2003 12:44:28 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/11/2003 12:51:07 PM, Serialize complete at 11/11/2003 12:51:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0060FB8585256DDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060FB8585256DDB_= Content-Type: text/plain; charset="US-ASCII" Mark noted on 11/10/2003 08:46:22 PM: > ICAL disallows two identical vevents because the uid distinguishes > them. And ICAL defines if they have the same uid, then they are the same > object in a possible different state or time. Actually the prohibition is on concurrent repeat instances which are actually identified using both UID and RECURRENCE-ID but in a nutshell this is basically it. > ICAL does not disallow vevents that would be identical except for the > unique identifier. Yep. (See, Mark and I dont always disagree.) Lets not forget that CAP currently has a prohibition on creating duplicate BOOKED instances (CAP-12-e, p19): There MUST NOT BE more than one "BOOKED" state object in a calendar for the same "UID". 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 0060FB8585256DDB_= Content-Type: text/html; charset="US-ASCII"
Mark noted on 11/10/2003 08:46:22 PM:
> ICAL disallows two identical vevents because the uid distinguishes
> them. And ICAL defines if they have the same uid, then they are the same
> object in a possible different state or time.
Actually the prohibition is on concurrent repeat instances which are actually identified using both UID and RECURRENCE-ID but in a nutshell this is basically it.

> ICAL does not disallow vevents that would be identical except for the
> unique identifier.
Yep.  (See, Mark and I dont always disagree.)

Lets not forget that CAP currently has a prohibition on creating duplicate BOOKED instances (CAP-12-e, p19):

   There MUST NOT BE more than one "BOOKED" state object in a calendar
  for the same "UID".

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 0060FB8585256DDB_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 13:08:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13943 for ; Tue, 11 Nov 2003 13:08:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABHhBkT012407 for ; Tue, 11 Nov 2003 09:43:11 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABHhBr2012406 for ietf-calendar-bks; Tue, 11 Nov 2003 09:43:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABHh8kT012400 for ; Tue, 11 Nov 2003 09:43:10 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "G. Barnes" Cc: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 11 Nov 2003 12:34:10 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/11/2003 12:43:08 PM, Serialize complete at 11/11/2003 12:43:08 PM Content-Type: multipart/alternative; boundary="=_alternative 00600A2685256DDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00600A2685256DDB_= Content-Type: text/plain; charset="US-ASCII" Greg replied on 11/10/2003 07:58:43 PM: > 1) To move CAP along, I think we have to concede that the question of > unique ids for VALARMs was already considered, and unique ids were > considered good by almost everyone. From the archive, it appears this > was most heavily discussed November 2001-January 2002, and everyone > seemed to agree that alarmids of some sort were useful. For example, from: > > While we did discuss its addition back then, we did not cover all the bases (nor was the actual need discussed that I can see but thats a different topic). Undiscussed or answered bits that come to mind are: 1: The addition is NOT optional (see ABNF) so if someone creates a VEVENT with a VALARM without SEQUENCE (aka ALARMID) then its considered an illegal VALARM. This means that any iTIP gatewayd content without the required property is considered 'invalid'. This is not goodness. 2: CAP says: These local alarms are not to be forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property and the "ENABLE" parameter. That is, when someone sends a VEVENT with a VALARM on it, local alarms and the SEQUENCE and ENABLE bits are NOT sent. This is in direct conflict w/the ABNF of '1' which is what was previously decided on in that discussion you found: > I think we should declare that this is a '1' and not > a '0 or 1'. [Snip, snip] I agree. which would say tthat any and all VALARMs MUST have an identifier added no matter what. It seems the intent was to coerce CUAs into creating SEQUENCE (ALARMID) for those entries they are dealing with locally BUT it is NOT to be sent on the wire to others (at least thats how I read the CAP text above). If thats the case then the ABNF for this change MUST be '0' or '1', not '1' since the invites, reschedules, etc sent would have to strip off the new stuff (or the local stuff). Otherwise those items sent would have to have SEQUENCE (ALARMID) on them (to conform to the ABNF) and thats contrary to the current text (and I suspect the intent from that early work). 3: If we opt to make the SEQUENCE (ALARMID) property truely a '1' in the ABNF then some adjustments will need to happen to allow for legacy data that does NOT contain it. That is, if an invitation arrives via iMIP then in order for it to be put into the CS someone has to coerce the missing property onto it. However, is this identifier on alarms truely necessary when the entry is NOT "BOOKED"? I suspect not but Im open to discussion otherwise. (After all, whom ever assigned that new property value was NOT the Organzier so it should be considered a local change and thus not propigated to others.) 4: If we say that SEQUENCE (ALARMID) is to be used on all VALARMs in CAP, BOOKED or not, then we need to invent a new property parameter for SEQUENCE (ALARMID) to indicate if the property was created locally for legacy data or not and the property should not be propigated further. For example, if an iTIP invitation arrives without a SEQUENCE (ALARMID) property on it, the recipient is mandated to create one. However since it was locally created and not assigned by the Organzier it should not be propigated on a delegation notice that the CUA creates. Otherwise it violates the iTIP text on delegation since the delegation info has been modified from its original info (beyond what iTIP says to do for delegation tracking). Before we can move on, these undiscussed issues need to be resolved or they risk being indeterminate in CAP 1.0 and thus become interop issues. > 2) As for what's the use of duplicate alarms, what if I want to send > myself 20 e-mail messages to make sure I get the hint? Or have 5 windows > opening with blinking text? Who are we to say what a user might think is > useful? We already have prohibitions on duplicate repeat instances in iCalendar and we have duplicate BOOKED entry prohibitions in CAP so its not as if a duplicate, identical alarm prohibition would be that extraordinary. These existing prohibitions are despite that some folks may consider concurrent repeat instances useful. In any case, all of what you suggest can be done with autorepeating alarms: BEGIN:VALARM ACTION:EMAIL TRIGGER:-P1D REPEAT:20 DURATION:PT1S ATTENDEE:MAILTO:gsbarnes@host.com SUMMARY:*** REMINDER\: SEND AGENDA FOR IETF MEETING *** DESCRIPTION:Send out the draft agenda for the IETF WG Meeting tomorrow. Attached is a pointer the document template for the agenda file. ATTACH;FMTTYPE=application/binary:http://host.com/templates/agenda.doc END:VALARM BEGIN:VALARM ACTION:EMAIL TRIGGER:-PT15M REPEAT:20 DURATION:PT1S ATTENDEE:MAILTO:gsbarnes@host.com SUMMARY:*** ANOTHER REMINDER\: SEND AGENDA FOR IETF MEETING *** DESCRIPTION:Send out the final agenda for the IETF WG Meeting today. END:VALARM BEGIN:VALARM TRIGGER:-PT10M REPEAT:5 DURATION:PT1S ACTION:DISPLAY DESCRIPTION:IETF WG Meeting in Jabber 10:00 AM EST today! END:VALARM 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 00600A2685256DDB_= Content-Type: text/html; charset="US-ASCII"
Greg replied on 11/10/2003 07:58:43 PM:
> 1) To move CAP along, I think we have to concede that the question of
> unique ids for VALARMs was already considered, and unique ids were
> considered good by almost everyone.  From the archive, it appears this
> was most heavily discussed November 2001-January 2002, and everyone
> seemed to agree that alarmids of some sort were useful.  For example, from:
>
> <http://www.imc.org/ietf-calendar/mail-archive/msg02317.html>
While we did discuss its addition back then, we did not cover all the bases (nor was the actual need discussed that I can see but thats a different topic).  Undiscussed or answered bits that come to mind are:

1: The addition is NOT optional (see ABNF) so if someone creates a VEVENT with a VALARM without SEQUENCE (aka ALARMID) then its considered an illegal VALARM.  This means that any iTIP gatewayd content without the required property is considered 'invalid'.  This is not goodness.

2: CAP says:

                                      These local alarms are not to be
  forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property
  and the "ENABLE" parameter.

That is, when someone sends a VEVENT with a VALARM on it, local alarms and the SEQUENCE and ENABLE bits are NOT sent.  This is in direct conflict w/the ABNF of '1' which is what was previously decided on in that discussion you found:

> I think we should declare that this is a '1' and not
> a '0 or 1'. [Snip, snip]

I agree.  

which would say tthat any and all VALARMs MUST have an identifier added no matter what.  It seems the intent was to coerce CUAs into creating SEQUENCE (ALARMID) for those entries they are dealing with locally BUT it is NOT to be sent on the wire to others (at least thats how I read the CAP text above).  If thats the case then the ABNF for this change MUST be '0' or '1', not '1' since the invites, reschedules, etc sent would have to strip off the new stuff (or the local stuff).  Otherwise those items sent would have to have SEQUENCE (ALARMID) on them (to conform to the ABNF) and thats contrary to the current text (and I suspect the intent from that early work).

3: If we opt to make the SEQUENCE (ALARMID) property truely a '1' in the ABNF then some adjustments will need to happen to allow for legacy data that does NOT contain it.  That is, if an invitation arrives via iMIP then in order for it to be put into the CS someone has to coerce the missing property onto it.  However, is this identifier on alarms truely necessary when the entry is NOT "BOOKED"?  I suspect not but Im open to discussion otherwise.   (After all, whom ever assigned that new property value was NOT the Organzier so it should be considered a local change and thus not propigated to others.)

4: If we say that SEQUENCE (ALARMID) is to be used on all VALARMs in CAP, BOOKED or not, then we need to invent a new property parameter for SEQUENCE (ALARMID) to indicate if the property was created locally for legacy data or not and the property should not be propigated further.  For example, if an iTIP invitation arrives without a SEQUENCE (ALARMID) property on it, the recipient is mandated to create one.  However since it was locally created and not assigned by the Organzier it should not be propigated on a delegation notice that the CUA creates.  Otherwise it violates the iTIP text on delegation since the delegation info has been modified from its original info (beyond what iTIP says to do for delegation tracking).

Before we can move on, these undiscussed issues need to be resolved or they risk being indeterminate in CAP 1.0 and thus become interop issues.

> 2) As for what's the use of duplicate alarms, what if I want to send
> myself 20 e-mail messages to make sure I get the hint?  Or have 5 windows
> opening with blinking text?  Who are we to say what a user might think is
> useful?
We already have prohibitions on duplicate repeat instances in iCalendar and we have duplicate BOOKED entry prohibitions in CAP so its not as if a duplicate, identical alarm prohibition would be that extraordinary.  These existing prohibitions are despite that some folks may consider concurrent repeat instances useful.

In any case, all of what you suggest can be done with autorepeating alarms:

     BEGIN:VALARM
    ACTION:EMAIL
    TRIGGER:-P1D
     REPEAT:20
    DURATION:PT1S
    ATTENDEE:MAILTO:gsbarnes@host.com
    SUMMARY:*** REMINDER\: SEND AGENDA FOR IETF MEETING ***
    DESCRIPTION:Send out the draft agenda for the IETF WG Meeting tomorrow.  Attached is a
      pointer the document template for the agenda file.
    ATTACH;FMTTYPE=application/binary:http://host.com/templates/agenda.doc
     END:VALARM

     BEGIN:VALARM
    ACTION:EMAIL
    TRIGGER:-PT15M
     REPEAT:20
    DURATION:PT1S
    ATTENDEE:MAILTO:gsbarnes@host.com
    SUMMARY:*** ANOTHER REMINDER\: SEND AGENDA FOR IETF MEETING ***
    DESCRIPTION:Send out the final agenda for the IETF WG Meeting today.
     END:VALARM

     BEGIN:VALARM
    TRIGGER:-PT10M
    REPEAT:5
    DURATION:PT1S
    ACTION:DISPLAY
    DESCRIPTION:IETF WG Meeting in Jabber 10:00 AM EST today!
    END:VALARM

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 00600A2685256DDB_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 14:12:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15906 for ; Tue, 11 Nov 2003 14:12:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABIrIkT015255 for ; Tue, 11 Nov 2003 10:53:18 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABIrIGP015254 for ietf-calendar-bks; Tue, 11 Nov 2003 10:53:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABIrGkT015245 for ; Tue, 11 Nov 2003 10:53:16 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hABIrCXK000327 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 11 Nov 2003 10:53:13 -0800 Message-ID: <3FB13013.4020102@Royer.com> Date: Tue, 11 Nov 2003 11:53:07 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080502060009000705090204" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080502060009000705090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Greg replied on 11/10/2003 07:58:43 PM: > > 1) To move CAP along, I think we have to concede that the question of > > unique ids for VALARMs was already considered, and unique ids were > > considered good by almost everyone. From the archive, it appears this > > was most heavily discussed November 2001-January 2002, and everyone > > seemed to agree that alarmids of some sort were useful. For > example, from: > > > > > > While we did discuss its addition back then, we did not cover all the > bases (nor was the actual need discussed that I can see but thats a > different topic). Undiscussed or answered bits that come to mind are: Give it up, you claimed it was not discussed, it was. You *always* claim that something you do not want is undiscussed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080502060009000705090204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTExMTg1MzA3WjAjBgkqhkiG9w0BCQQxFgQUSr5+cn6SiIfyrQibqqq4 GJuevhkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAuq3GKm1ItWR8cuoN9K3fhDLwWTX3BE58hVYlI3RyvlzReXwXfbq8W7whPkRyh0hA UMJyvoaKV3egRGv9o46CFZ2RnbGXhkrku/7GI4QNnXnLlHtdWDW20Lf5DvKeZ5XKkaDbMPt6 Q/Fbe5oqFFcLh02DWxm1MbSZ7EMwHSm9FphB6zVTdTe2Nw70bKn2DR2I6GuNI+vwayz29hkH FX3n6C6tQ1VICxe7x0Mkx32AqNlkLbFOJM5Ie9EP/XMbfWk3Eq704WspHpYxL1kom+10S624 HD5wwBWZe0qlBLaq6MhgyvFyehZ7x+LKqiNHJbj4wXkG3ElHryg/6oRAOGArAAAAAAAAAA== --------------ms080502060009000705090204-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 14:12:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15922 for ; Tue, 11 Nov 2003 14:12:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABIv1kT015463 for ; Tue, 11 Nov 2003 10:57:01 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABIv1Pa015462 for ietf-calendar-bks; Tue, 11 Nov 2003 10:57:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABIv0kT015449 for ; Tue, 11 Nov 2003 10:57:00 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hABIuu84008410 for ; Tue, 11 Nov 2003 11:56:56 -0700 (MST) Message-ID: <3FB130F8.E3CA8F2B@INET-Calendar.net> Date: Tue, 11 Nov 2003 11:56:56 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark noted on 11/10/2003 08:46:22 PM: > > ICAL disallows two identical vevents because the uid distinguishes > > them. And ICAL defines if they have the same uid, then they are the > same > > object in a possible different state or time. > > Actually the prohibition is on concurrent repeat instances which are > actually identified using both UID and RECURRENCE-ID but in a nutshell > this is basically it. > > > ICAL does not disallow vevents that would be identical except for > the > > unique identifier. > > Yep. (See, Mark and I dont always disagree.) > > Lets not forget that CAP currently has a prohibition on creating > duplicate BOOKED instances (CAP-12-e, p19): > > There MUST NOT BE more than one "BOOKED" state object in a calendar > for the same "UID". Which is completely unrelated to the topic of should valarms have a unique identifier. Whats your point? From owner-ietf-calendar@mail.imc.org Tue Nov 11 14:13:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15938 for ; Tue, 11 Nov 2003 14:13:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABItEkT015397 for ; Tue, 11 Nov 2003 10:55:14 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABItEth015396 for ietf-calendar-bks; Tue, 11 Nov 2003 10:55:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABItCkT015391 for ; Tue, 11 Nov 2003 10:55:12 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hABItBXK000377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 11 Nov 2003 10:55:12 -0800 Message-ID: <3FB1308A.2080101@Royer.com> Date: Tue, 11 Nov 2003 11:55:06 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050505000606020507080609" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050505000606020507080609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Mark noted on 11/10/2003 08:46:22 PM: > > ICAL disallows two identical vevents because the uid distinguishes > > them. And ICAL defines if they have the same uid, then they are the same > > object in a possible different state or time. > > Actually the prohibition is on concurrent repeat instances which are > actually identified using both UID and RECURRENCE-ID but in a nutshell > this is basically it. > > > ICAL does not disallow vevents that would be identical except for the > > unique identifier. > > Yep. (See, Mark and I dont always disagree.) > > Lets not forget that CAP currently has a prohibition on creating > duplicate BOOKED instances (CAP-12-e, p19): > > There MUST NOT BE more than one "BOOKED" state object in a calendar > for the same "UID". The SUBJECT is Alarms/SEQUENCE ??? No one disputes that VEVENTS must have a unique ID. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050505000606020507080609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTExMTg1NTA2WjAjBgkqhkiG9w0BCQQxFgQU2wItFlCaNH8RKEiEdZCp mfwROHkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA20yto2H4WD2dhurIUNeptIu5bltnT8I1wP1xPsWPG0w/GH9cak/FIOI81xlBhg/2 YpMeaNts2LH/BtDLz54EtwxLON4/Gq4gNqnbjs8naiBWJIOrzaz5BUuAOwX3VW2wwWjzl98N oIiTtT0Wa0Waj4UYQ4JhAC6Mcg/8VzPlENq7rgQSJXJi9CYWaD6G+7GWTxgI59jRYo918SSl jxeta55AfyZjqRI+SYRzOOJyClQRvyuVW3SZzvRWrrHOPGCcczJePgdjEeV+zmPf2cPtNvkl AecGQAAwlWb6ijDV9o723CIz9e8PEM6QIVefbZQWZfZ4mOuXcxSUJemrBXNNVAAAAAAAAA== --------------ms050505000606020507080609-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 14:25:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16425 for ; Tue, 11 Nov 2003 14:25:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJ6xkT015817 for ; Tue, 11 Nov 2003 11:06:59 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABJ6xL5015816 for ietf-calendar-bks; Tue, 11 Nov 2003 11:06:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJ6tkT015804 for ; Tue, 11 Nov 2003 11:06:57 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3FB02F19.2060109@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP-12-e: Changing REQUEST-STATUS MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 11 Nov 2003 13:35:38 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/11/2003 02:06:52 PM, Serialize complete at 11/11/2003 02:06:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0065AA9885256DDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065AA9885256DDB_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/10/2003 07:36:41 PM: > I think it is supposed to be: > > statcode ";" [ statdesc ] ";" [extdata] The change was originally proposed by George back on 08/18/2000 04:46:33 PM AST with the justification label of: Changes needed by CAP. When I asked about this need there was no response and thats where it was left on 22-Aug-2000. Doug had referred to a concern about the language of the contents of statdesc but thats secondary to the proposed change (and would affect ALL properties in iCal, not just stadesc on REQUEST-STATUS) As originally noted in http://www.imc.org/ietf-calendar/mail-archive/msg00680.html there is no need to revise the ABNF from its current state in order to make statdesc optional if you properly follow the ABNF in 2445: Read the ABNF for statdesc and you will see "Textual status description". So while the actual contents of that are not mandated (nor are they for LOCATION, CLASS, etc) the _kind_ of data is described. Its up to implementations to put in something useful. See thoughts above on the _intent_ of statdesc if still necessary... Also, if you really read the ABNF you will see that NULL is also valid! The ABNF for statdesc is: statdesc = text ;Textual status description and we defined text as: text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) Note the *() format so NULL is already an option. The only difference between this proposal and the one we already have in RFC 2445 is effectively to remove the mandated semicolon after the statcode. Thats it! This proposed change to REQUEST-STATUS essentialy boils down to CAP wanting to always have the trailing semicolon to delimit the end of the optional statdesc. That is instead of the current: REQUEST-STATUS:2.0; a CAP implementation would have to use: REQUEST-STATUS:2.0;; This change would be a non-backwards compatible one too. If CAP cannot demonstrate a need for the ABNF to change in iCalendar, it should not be done. Especially if it will break interop with no particular benefit or need. 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 0065AA9885256DDB_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/10/2003 07:36:41 PM:
> I think it is supposed to be:
>
>     statcode ";" [ statdesc ] ";" [extdata]
The change was originally proposed by George back on 08/18/2000 04:46:33 PM AST with the justification label of:

Changes needed by CAP.

When I asked about this need there was no response and thats where it was left on 22-Aug-2000.

Doug had referred to a concern about the language of the contents of statdesc but thats secondary to the proposed change (and would affect ALL properties in iCal, not just stadesc on REQUEST-STATUS)

As originally noted in http://www.imc.org/ietf-calendar/mail-archive/msg00680.html there is no need to revise the ABNF from its current state in order to make statdesc optional if you properly follow the ABNF in 2445:

Read the ABNF for statdesc and you will see "Textual status description".  So while the actual contents of that are not mandated (nor are they for LOCATION, CLASS, etc) the _kind_ of data is described.  Its up to implementations to put in something useful.  See thoughts above on the _intent_ of statdesc if still necessary...

Also, if you really read the ABNF you will see that NULL is also valid!  The ABNF for statdesc is:

   statdesc   = text
   ;Textual status description

and we defined text as:

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

Note the *() format so NULL is already an option.  The only difference between this proposal and the one we already have in RFC 2445 is effectively to remove the mandated semicolon after the statcode.  Thats it!  

This proposed change to REQUEST-STATUS essentialy boils down to CAP wanting to always have the trailing semicolon to delimit the end of the optional statdesc.  That is instead of the current:

REQUEST-STATUS:2.0;

a CAP implementation would have to use:

REQUEST-STATUS:2.0;;
This change would be a non-backwards compatible one too.  If CAP cannot demonstrate a need for the ABNF to change in iCalendar, it should not be done.  Especially if it will break interop with no particular benefit or need.

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 0065AA9885256DDB_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 11 15:03:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18547 for ; Tue, 11 Nov 2003 15:03:24 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJhhkT017575 for ; Tue, 11 Nov 2003 11:43:43 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABJhh8K017574 for ietf-calendar-bks; Tue, 11 Nov 2003 11:43:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJhgkT017565 for ; Tue, 11 Nov 2003 11:43:42 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hABJhd84014963 for ; Tue, 11 Nov 2003 12:43:39 -0700 (MST) Message-ID: <3FB13BEB.A1D99875@INET-Calendar.net> Date: Tue, 11 Nov 2003 12:43:39 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12-e: Changing REQUEST-STATUS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > This change would be a non-backwards compatible one too. If CAP > cannot demonstrate a need for the ABNF to change in iCalendar, it > should not be done. Especially if it will break interop with no > particular benefit or need. Don't you find it odd that you declare everyone that took part in that debate as misunderstanding the topic - except you? Did it really take you 3 years to notice this? Looking a those same archives - you participated in that discussion. Could you at least post a fix once in a while and not just declare that it was made as you just posted a few days ago: (Bruce) "In looking up something related to CALSCALE I noticed that CAP-12-e makes an unmentioned change to iCalendars REQUEST-STATUS property. This change is NOT good NOR is it necessary. " You participated in that debate 3 years ago and yet you seem to have indicated (above in the full post) that there was a change made without your or the lists permission. Do you not see how that can be seen as abusive to this list? Would you please read the archives and search for topic before posting more misinformation that causes others to have to do your work and lookup the history only to find again that you posted an incorrect history of events. Will you ever be embarrassed by your continual errors you post? Can you ever live with something that is not 100% your way? Lets get CAP out the door. Yes this needs fixed but your post forced me (and I will bet others) have to re read the archives only to conclude that your original post had false information. At least this one you caught before this got into a big debate. There was no -12-e change to the ABNF - your fears or whatever are causing this list grief when you cause others to have to lookup your contributions to see if what you say is valid. So far of your original posts to a topic you are running about 5% accuracy as as whole on your first post (I counted from Jan-2003). Causing others to have to redig over and over again into the archives because you shoot from the hip. From owner-ietf-calendar@mail.imc.org Tue Nov 11 15:33:46 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20687 for ; Tue, 11 Nov 2003 15:33:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKEVkT019182 for ; Tue, 11 Nov 2003 12:14:31 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABKEV2V019181 for ietf-calendar-bks; Tue, 11 Nov 2003 12:14:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.exchange.ximian.com (mr-nutty.ximian.com [141.154.95.31]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABKEUkT019170 for ; Tue, 11 Nov 2003 12:14:30 -0800 (PST) (envelope-from danw@ximian.com) Received: from twelve-monkeys by owa.ximian.com; 11 Nov 2003 15:20:37 -0500 Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) From: Dan Winship To: Mark Smith Cc: ietf-calendar@imc.org In-Reply-To: <3FB130F8.E3CA8F2B@INET-Calendar.net> References: <3FB130F8.E3CA8F2B@INET-Calendar.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068582037.2215.27.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 11 Nov 2003 15:20:37 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Go away or I will replace you with a very small procmail script[1] :0 * ^From.*Bruce_Kahn | (formail -kr; echo "No, you're wrong! Neener neener neener!) | sendmail -t [1] http://www.thinkgeek.com/tshirts/frustrations/374d/ On Tue, 2003-11-11 at 13:56, Mark Smith wrote: > Bruce_Kahn@notesdev.ibm.com wrote: > > > > Mark noted on 11/10/2003 08:46:22 PM: > > > ICAL disallows two identical vevents because the uid distinguishes > > > them. And ICAL defines if they have the same uid, then they are the > > same > > > object in a possible different state or time. > > > > Actually the prohibition is on concurrent repeat instances which are > > actually identified using both UID and RECURRENCE-ID but in a nutshell > > this is basically it. > > > > > ICAL does not disallow vevents that would be identical except for > > the > > > unique identifier. > > > > Yep. (See, Mark and I dont always disagree.) > > > > Lets not forget that CAP currently has a prohibition on creating > > duplicate BOOKED instances (CAP-12-e, p19): > > > > There MUST NOT BE more than one "BOOKED" state object in a calendar > > for the same "UID". > > Which is completely unrelated to the topic of should valarms > have a unique identifier. Whats your point? > From owner-ietf-calendar@mail.imc.org Tue Nov 11 17:47:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25832 for ; Tue, 11 Nov 2003 17:47:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABMSFkT024926 for ; Tue, 11 Nov 2003 14:28:15 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hABMSFVa024925 for ietf-calendar-bks; Tue, 11 Nov 2003 14:28:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABMSEkT024919 for ; Tue, 11 Nov 2003 14:28:14 -0800 (PST) (envelope-from gsbarnes@u.washington.edu) Received: from mead12.u.washington.edu (mead12.u.washington.edu [140.142.12.176]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hABMSB0Y002490 for ; Tue, 11 Nov 2003 14:28:16 -0800 Received: from localhost (gsbarnes@localhost) by mead12.u.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hABMSBhU905422 for ; Tue, 11 Nov 2003 14:28:11 -0800 Date: Tue, 11 Nov 2003 14:28:10 -0800 (PST) From: "G. Barnes" To: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 11 Nov 2003 Bruce_Kahn@notesdev.ibm.com wrote: > Greg replied on 11/10/2003 07:58:43 PM: > > 2) As for what's the use of duplicate alarms, what if I want to send > > myself 20 e-mail messages to make sure I get the hint? Or have 5 > windows > > opening with blinking text? Who are we to say what a user might think > is > > useful? [...] > In any case, all of what you suggest can be done with autorepeating > alarms: > > BEGIN:VALARM > ACTION:EMAIL > TRIGGER:-P1D > REPEAT:20 > DURATION:PT1S [...] I've mostly said what I wanted to say, and don't want to repeat myself too much, but here, I must emphasize that you seem to be assuming too much. What if a) The CUA doesn't allow repeats? b) Or doesn't allow repeats with a duration anywhere as short as 1 second? c) Or allows them, but to get them you have to use some advanced function that the user doesn't know or doesn't want to know? I fail to see the harm in duplicate alarms, and judging from the discussions I've read in the archive, I think the matter was considered by many other people, and unique ids for alarms were considered a good thing. Yeah, sure, we can reconsider it, but if you're interested in doing the simplest thing, reopening old issues isn't what you want to be doing. Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Wed Nov 12 10:45:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23088 for ; Wed, 12 Nov 2003 10:45:57 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFIjkT029510 for ; Wed, 12 Nov 2003 07:18:45 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACFIjk4029509 for ietf-calendar-bks; Wed, 12 Nov 2003 07:18:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.notesdev.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACFIikT029501 for ; Wed, 12 Nov 2003 07:18:45 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: "G. Barnes" Cc: ietf-calendar@imc.org Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_10202003NP October 20, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 12 Nov 2003 10:18:35 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.2CF2|July 23, 2003) at 11/12/2003 10:18:33 AM, Serialize complete at 11/12/2003 10:18:33 AM Content-Type: multipart/alternative; boundary="=_alternative 00539AA485256DDC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00539AA485256DDC_= Content-Type: text/plain; charset="US-ASCII" George replied on 11/11/2003 05:28:10 PM: > What if > a) The CUA doesn't allow repeats? > b) Or doesn't allow repeats with a duration anywhere as short as 1 second? > c) Or allows them, but to get them you have to use some advanced function > that the user doesn't know or doesn't want to know? All interesting questions / scenarios. I would think that any CUA capable of distinguishing between 20 identical duplicate alarms would allow something like repeats but perhaps not. Still though they are valid questions... > I fail to see the harm in duplicate alarms, and judging from the discussions > I've read in the archive, I think the matter was considered by many other > people, and unique ids for alarms were considered a good thing. Yeah, sure, > we can reconsider it, but if you're interested in doing the simplest thing, > reopening old issues isn't what you want to be doing. The only thing that I question regarding the original discussion was the practicality of multiple exact duplicates considering its not something available in any shipping product now that Im aware of. In any case, I do question the undiscussed change of ALARMID to SEQUENCE (including the misreuse of SEQUENCE as an identifier instead of a change tracker). In evaluating the actual application I also came up with the 4 questions I posted before. Contrary to WG discussion before, I think the ABNF for this change needs to be '0' or '1', not '1' for technical reasons previously mentioned. Doing this and making it clear that the identifer is ONLY for BOOKED entries and is never sent as part of workflow should resolve 'em I think. However Im interested to hear if there are alternate ideas. 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 00539AA485256DDC_= Content-Type: text/html; charset="US-ASCII"
George replied on 11/11/2003 05:28:10 PM:
> What if
> a) The CUA doesn't allow repeats?
> b) Or doesn't allow repeats with a duration anywhere as short as 1 second?
> c) Or allows them, but to get them you have to use some advanced function
>    that the user doesn't know or doesn't want to know?
All interesting questions / scenarios.  I would think that any CUA capable of distinguishing between 20 identical duplicate alarms would allow something like repeats but perhaps not.  Still though they are valid questions...

> I fail to see the harm in duplicate alarms, and judging from the discussions
> I've read in the archive, I think the matter was considered by many other
> people, and unique ids for alarms were considered a good thing.  Yeah, sure,
> we can reconsider it, but if you're interested in doing the simplest thing,
> reopening old issues isn't what you want to be doing.
The only thing that I question regarding the original discussion was the practicality of multiple exact duplicates considering its not something available in any shipping product now that Im aware of.

In any case, I do question the undiscussed change of ALARMID to SEQUENCE (including the misreuse of SEQUENCE as an identifier instead of a change tracker).  In evaluating the actual application I also came up with the 4 questions I posted before.  

Contrary to WG discussion before, I think the ABNF for this change needs to be '0' or '1', not '1' for technical reasons previously mentioned.  Doing this and making it clear that the identifer is ONLY for BOOKED entries and is never sent as part of workflow should resolve 'em I think.  However Im interested to hear if there are alternate ideas.

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 00539AA485256DDC_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 13 11:29:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06075 for ; Thu, 13 Nov 2003 11:29:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADG5ZkT064235 for ; Thu, 13 Nov 2003 08:05:35 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADG5Zfl064234 for ietf-calendar-bks; Thu, 13 Nov 2003 08:05:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-calendar.net ([12.110.13.99]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADG5YkT064225 for ; Thu, 13 Nov 2003 08:05:34 -0800 (PST) (envelope-from mark@inet-calendar.net) Received: from INET-Calendar.net (inet-calendar.net [192.168.169.20]) by inet-calendar.net (8.12.9/8.12.9) with ESMTP id hADG5U84014995 for ; Thu, 13 Nov 2003 09:05:30 -0700 (MST) Message-ID: <3FB3ABCA.A351498C@INET-Calendar.net> Date: Thu, 13 Nov 2003 09:05:30 -0700 From: Mark Smith X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: TEST Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit My mail server went down over the weekend - test. From owner-ietf-calendar@mail.imc.org Thu Nov 13 11:59:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07947 for ; Thu, 13 Nov 2003 11:59:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADGiIkT066450 for ; Thu, 13 Nov 2003 08:44:18 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADGiI6o066449 for ietf-calendar-bks; Thu, 13 Nov 2003 08:44:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from trout.cpsr.org (trout.cpsr.org [66.180.229.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADGiHkT066441 for ; Thu, 13 Nov 2003 08:44:17 -0800 (PST) (envelope-from nsb@guppylake.com) Received: from guppylake.com (trout [66.180.229.5]) by trout.cpsr.org (8.12.8p2/8.12.8) with ESMTP id hADGhtta095320; Thu, 13 Nov 2003 08:44:11 -0800 (PST) (envelope-from nsb@guppylake.com) Date: Thu, 13 Nov 2003 11:45:05 -0500 Subject: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Nathaniel Borenstein To: ietf-calendar@imc.org Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hADGiHkT066442 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The CALSCH WG (really a minor fraction thereof) met in Minneapolis.   Both WG chairs and the editor of the only open document were absent (the latter due to Jabber-related technical difficulties) from the meeting.  At the invitation of Pat Egen, I chaired the meeting.   Obviously the absence of so many key people made a major decision inappropriate.  However, there was apparent consensus for considering several steps that we hope will reinvigorate the WG, and that we are proposing to the mailing list for wider consideration. 1.  The Changing of the Bobs:  Bob Morgan has volunteered to come in as WG chair in place of Bob Mahoney, who has been under increasing time pressure and wishes to step down. 2.  The Changing of the Bards:  I have volunteered to perform One More Round of edits on the CAP document, with an eye to having a Last Call for Proposed Standard status by March.  I want to express my gratitude to Doug Royer for getting the document to the point where the remaining problems are small enough for me to view that as an easy target date. 3.  The Changing of the Paradigms:  Lisa Dusseault has volunteered to write a first outline of what a WebDAV-enabled calendar access mechanism might look like. 4.  The Changing of the Version:  There was general consensus that, CAP aside, the rest of the ical documents have been around long enough and had enough implementations that it is time to review and amend them all.  Accordingly, Bob Morgan has volunteered to draft a new charter for the WG, and Ned Freed and Nathaniel Borenstein have both volunteered to work on that next round of document revisions. I look forward to your comments on these proposals.  -- Nathaniel From owner-ietf-calendar@mail.imc.org Thu Nov 13 12:18:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08871 for ; Thu, 13 Nov 2003 12:18:01 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADH5CkT067300 for ; Thu, 13 Nov 2003 09:05:12 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADH5CPb067299 for ietf-calendar-bks; Thu, 13 Nov 2003 09:05:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ardeo.com (hidden-user@[80.69.0.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADH59kT067291 for ; Thu, 13 Nov 2003 09:05:11 -0800 (PST) (envelope-from j.smith@ardeo.com) Received: from devcompaq1 dsl-62-3-124-190.zen.co.uk by ardeo.com (MDaemon.PRO.v6.8.5.R) with ESMTP id 34-md50000000358.tmp for ; Thu, 13 Nov 2003 17:05:41 +0000 From: "Jim Smith" To: Subject: RE: TEST Date: Thu, 13 Nov 2003 17:05:48 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3FB3ABCA.A351498C@INET-Calendar.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: ardeo.com, Thu, 13 Nov 2003 17:05:41 +0000 (not processed: message from valid local sender) X-Lookup-Warning: HELO/EHLO lookup on devcompaq1 does not match 62.3.124.190 X-Return-Path: j.smith@ardeo.com X-MDaemon-Deliver-To: ietf-calendar@imc.org Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > My mail server went down over the weekend - test. > The most constructive comment you've made yet. From owner-ietf-calendar@mail.imc.org Fri Nov 14 18:43:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05526 for ; Fri, 14 Nov 2003 18:43:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAENShkT044536 for ; Fri, 14 Nov 2003 15:28:43 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAENShmj044535 for ietf-calendar-bks; Fri, 14 Nov 2003 15:28:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAENSfkT044527 for ; Fri, 14 Nov 2003 15:28:41 -0800 (PST) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAENScaZ030197 for ; Fri, 14 Nov 2003 15:28:43 -0800 Received: from ip68-111-64-87.oc.oc.cox.net (ip68-111-64-87.oc.oc.cox.net [68.111.64.87]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAENSbSS026608 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 14 Nov 2003 15:28:38 -0800 Date: Fri, 14 Nov 2003 15:28:35 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: IETF calsch WG Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 13 Nov 2003, Nathaniel Borenstein wrote: > 1. The Changing of the Bobs: Bob Morgan has volunteered to come in as > WG chair in place of Bob Mahoney, who has been under increasing time > pressure and wishes to step down. For those who may not know me, I am currently co-chair of the ldapbis WG, which is nearing completion, and have been hanging around IETF and the apps area since 1989. I have not been deeply involved in calendar work, but am somewhat associated with the calendar software implementation going on here at the University of Washington. I expect my role, assuming this change is finalized, will be the process guy. - RL "Bob" From owner-ietf-calendar@mail.imc.org Sat Nov 15 10:38:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10873 for ; Sat, 15 Nov 2003 10:38:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFFPvkT071183 for ; Sat, 15 Nov 2003 07:25:57 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAFFPvfG071182 for ietf-calendar-bks; Sat, 15 Nov 2003 07:25:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFFPtkT071168 for ; Sat, 15 Nov 2003 07:25:55 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: To: "RL 'Bob' Morgan" Cc: IETF calsch WG , owner-ietf-calendar@mail.imc.org Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Sat, 15 Nov 2003 10:25:54 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/15/2003 10:25:56 AM, Serialize complete at 11/15/2003 10:25:57 AM, Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 11/15/2003 10:25:57 AM Content-Type: multipart/alternative; boundary="=_alternative 0054C4F085256DDF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054C4F085256DDF_= Content-Type: text/plain; charset="US-ASCII" Thanks for taking on this effort. owner-ietf-calendar@mail.imc.org wrote on 11/14/2003 18:28:35: > > > On Thu, 13 Nov 2003, Nathaniel Borenstein wrote: > > > 1. The Changing of the Bobs: Bob Morgan has volunteered to come in as > > WG chair in place of Bob Mahoney, who has been under increasing time > > pressure and wishes to step down. > > For those who may not know me, I am currently co-chair of the ldapbis WG, > which is nearing completion, and have been hanging around IETF and the > apps area since 1989. I have not been deeply involved in calendar work, > but am somewhat associated with the calendar software implementation going > on here at the University of Washington. I expect my role, assuming this > change is finalized, will be the process guy. > > - RL "Bob" > --=_alternative 0054C4F085256DDF_= Content-Type: text/html; charset="US-ASCII"
Thanks for taking on this effort.


owner-ietf-calendar@mail.imc.org wrote on 11/14/2003 18:28:35:

>
>
> On Thu, 13 Nov 2003, Nathaniel Borenstein wrote:
>
> > 1. The Changing of the Bobs:  Bob Morgan has volunteered to come in as
> > WG chair in place of Bob Mahoney, who has been under increasing time
> > pressure and wishes to step down.
>
> For those who may not know me, I am currently co-chair of the ldapbis WG,
> which is nearing completion, and have been hanging around IETF and the
> apps area since 1989.  I have not been deeply involved in calendar work,
> but am somewhat associated with the calendar software implementation going
> on here at the University of Washington.  I expect my role, assuming this
> change is finalized, will be the process guy.
>
>  - RL "Bob"
>
--=_alternative 0054C4F085256DDF_=-- From owner-ietf-calendar@mail.imc.org Sat Nov 15 21:39:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00616 for ; Sat, 15 Nov 2003 21:39:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAG2OrkT004729 for ; Sat, 15 Nov 2003 18:24:53 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAG2Ors3004728 for ietf-calendar-bks; Sat, 15 Nov 2003 18:24:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAG2OpkT004718 for ; Sat, 15 Nov 2003 18:24:52 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc13) with SMTP id <2003111602244801600i0jq4e> (Authid: TimHare); Sun, 16 Nov 2003 02:24:49 +0000 Message-Id: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 15 Nov 2003 21:18:15 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will have to look up what WebDAV is, but the rest of it sounds OK to me. I wonder if we should also, during our review process, look over the RDF calendar work to see where we can improve synergy with those efforts. At this point I don't understand RDF/Semantic Web items at a deep enough theoretical level but as an old, old, user of markup languages I do "get" the benefits of XML and I believe there were folks who took the xCal work and tried to extend it into RDF? XML also would allow RSS "feeds" of published calendar info such as schedules. Tim Hare Interested Bystander, Non-Inc. At 11:45 AM 11/13/03 -0500, Nathaniel Borenstein wrote: >The CALSCH WG (really a minor fraction thereof) met in Minneapolis. >Both WG chairs and the editor of the only open document were absent >(the latter due to Jabber-related technical difficulties) from the >meeting. At the invitation of Pat Egen, I chaired the meeting. >Obviously the absence of so many key people made a major decision >inappropriate. However, there was apparent consensus for considering >several steps that we hope will reinvigorate the WG, and that we are >proposing to the mailing list for wider consideration. > >1. The Changing of the Bobs: Bob Morgan has volunteered to come in as >WG chair in place of Bob Mahoney, who has been under increasing time >pressure and wishes to step down. > >2. The Changing of the Bards: I have volunteered to perform One More >Round of edits on the CAP document, with an eye to having a Last Call >for Proposed Standard status by March. I want to express my gratitude >to Doug Royer for getting the document to the point where the remaining >problems are small enough for me to view that as an easy target date. > >3. The Changing of the Paradigms: Lisa Dusseault has volunteered to >write a first outline of what a WebDAV-enabled calendar access >mechanism might look like. > >4. The Changing of the Version: There was general consensus that, CAP >aside, the rest of the ical documents have been around long enough and >had enough implementations that it is time to review and amend them >all. Accordingly, Bob Morgan has volunteered to draft a new charter >for the WG, and Ned Freed and Nathaniel Borenstein have both >volunteered to work on that next round of document revisions. > >I look forward to your comments on these proposals. -- Nathaniel > > From owner-ietf-calendar@mail.imc.org Sat Nov 15 22:24:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01512 for ; Sat, 15 Nov 2003 22:24:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAG3DRkT006526 for ; Sat, 15 Nov 2003 19:13:27 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAG3DRlE006525 for ietf-calendar-bks; Sat, 15 Nov 2003 19:13:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAG3DQkT006519 for ; Sat, 15 Nov 2003 19:13:26 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Zj3y6hb9/0p/qRlK1ftpa8FbUSbO/Ixg@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAG3DQa9007051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 15 Nov 2003 19:13:26 -0800 Message-ID: <3FB6EB55.3030406@Royer.com> Date: Sat, 15 Nov 2003 20:13:25 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010701070300080807000207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010701070300080807000207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Oops - this was supposed to be to the list... -------- Original Message -------- > Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 > Date: Sat, 15 Nov 2003 20:10:09 -0700 > From: Doug Royer Organization: http://INET-Consulting.com > To: Tim Hare > I will have to look up what WebDAV is, but the rest of it sounds OK to > me. I wonder if we should also, during our review process, look over > the RDF calendar work to see where we can improve synergy with those > efforts. At this point I don't understand RDF/Semantic Web items at a > deep enough theoretical level but as an old, old, user of markup > languages I do "get" the benefits of XML and I believe there were > folks who took the xCal work and tried to extend it into RDF? XML > also would allow RSS "feeds" of published calendar info such as > schedules. As all of the WebDAV implementations that I can find get/put .ics files and only one that I can find also supports RSS, I think if WebDAV makes it (and I hope it does), it should be iCal-ish and allow XML as an add-on. Then it is a simply a new transport like CAP or iMIP. iCal <-> XML(RDF?/RSS) can be separate from WebDAV as it will restart the old debates. The xCal debates included the issues: Should we extend iCal? - I think that if this happens [please no], it should be separate from a unity translation of iCal) Some wanted it only if they could use XSLT. - I can use XSLT, but I do not care if code has to be written. Some that wanted XSLT to be able to create the objects, did not care if it was a two way translation. - I think any such draft MUST consider translating the data in both directions. In email, we were strongly informed that we should only allow xCal if it was a MUST that text/calendar also be included in the object. - I think that for compatibility we have to do this at least initially as iCal is still too new to obsolete which I think would be the effect. Some of us have been emailing privately on this topic - I do not mean to imply I am the originator of all of the above ideas. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010701070300080807000207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTE2MDMxMzI1WjAjBgkqhkiG9w0BCQQxFgQUPwT2A/IehvCupQS+juXk Yl+7Vn4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAi2891QUAWkQWhjeokruHmGjOgZOqaCK1iz7kq3QesZo8Fsc6JBnUxDpsSjL7dPux J3UgMnfF8H9mBsRGqgDdaBGFXApN/GRpvXXRQEAjlMDYHWnzpY9EuLVpxSAIwry0MukN64Cv 3YY1OlKQPtFxG/IsNkZB40aWw1X25zp6DSvx10fiPFrOEVFzCb8HhW1mkCj2M5XpOnGDGpyj 4DIKcnk8V1dAZ4hfSR9YgZiWMrCGhhSPdH+1wjYAioaivCuBjvkRQMI0LeQsmLmN+hUpXFqV B8hFGY3ydv++WdGIXS75VFu5MyjI3ujnO+fedCmgRXoaHddaJlnHuPDh+/GeQgAAAAAAAA== --------------ms010701070300080807000207-- From owner-ietf-calendar@mail.imc.org Sun Nov 16 08:16:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27651 for ; Sun, 16 Nov 2003 08:16:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAGD5BkT097810 for ; Sun, 16 Nov 2003 05:05:11 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAGD5BW7097809 for ietf-calendar-bks; Sun, 16 Nov 2003 05:05:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAGD59kT097804 for ; Sun, 16 Nov 2003 05:05:10 -0800 (PST) (envelope-from Libby.Miller@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Sun, 16 Nov 2003 13:05:08 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 1ALMFw-0006LU-00; Sun, 16 Nov 2003 12:43:57 +0000 Date: Sun, 16 Nov 2003 12:43:45 +0000 (GMT) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: Tim Hare cc: ietf-calendar@imc.org Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 In-Reply-To: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> Message-ID: References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: hi Tim, all, I've been following these discussions with interest, and was waiting for an opportunity to (re-)introduce myself. I lead the W3C RDF Interest group's calendaring taskforce (an informal group), and I'd be very interested to improve contact with the CALSCH WG. Within the past year, we have narrowed our remit to providing documentation and software for roundtripping between iCalendar and its RDF representation. You might be interested in a summary of our current mini-process here: http://swordfish.rdfweb.org/discovery/2003/11/rdfical/final-tidy.html (that document is a submission to the WWW2004 confernce) Perhaps the most relevant aspect is that we generate our RDF schema for iCalendar from test data, and not the other way around. We are therefore very interested in any sample data that is available. You can find our sample iCalendar files and the derived RDF files here: http://www.w3.org/2002/12/cal/test/ http://www.w3.org/2002/12/cal/ cheers, Libby On Sat, 15 Nov 2003, Tim Hare wrote: > > I will have to look up what WebDAV is, but the rest of it sounds OK to > me. I wonder if we should also, during our review process, look over the > RDF calendar work to see where we can improve synergy with those efforts. > At this point I don't understand RDF/Semantic Web items at a deep enough > theoretical level but as an old, old, user of markup languages I do "get" > the benefits of XML and I believe there were folks who took the xCal work > and tried to extend it into RDF? XML also would allow RSS "feeds" of > published calendar info such as schedules. > > Tim Hare > Interested Bystander, Non-Inc. > > At 11:45 AM 11/13/03 -0500, Nathaniel Borenstein wrote: > > >The CALSCH WG (really a minor fraction thereof) met in Minneapolis. > >Both WG chairs and the editor of the only open document were absent > >(the latter due to Jabber-related technical difficulties) from the > >meeting. At the invitation of Pat Egen, I chaired the meeting. > >Obviously the absence of so many key people made a major decision > >inappropriate. However, there was apparent consensus for considering > >several steps that we hope will reinvigorate the WG, and that we are > >proposing to the mailing list for wider consideration. > > > >1. The Changing of the Bobs: Bob Morgan has volunteered to come in as > >WG chair in place of Bob Mahoney, who has been under increasing time > >pressure and wishes to step down. > > > >2. The Changing of the Bards: I have volunteered to perform One More > >Round of edits on the CAP document, with an eye to having a Last Call > >for Proposed Standard status by March. I want to express my gratitude > >to Doug Royer for getting the document to the point where the remaining > >problems are small enough for me to view that as an easy target date. > > > >3. The Changing of the Paradigms: Lisa Dusseault has volunteered to > >write a first outline of what a WebDAV-enabled calendar access > >mechanism might look like. > > > >4. The Changing of the Version: There was general consensus that, CAP > >aside, the rest of the ical documents have been around long enough and > >had enough implementations that it is time to review and amend them > >all. Accordingly, Bob Morgan has volunteered to draft a new charter > >for the WG, and Ned Freed and Nathaniel Borenstein have both > >volunteered to work on that next round of document revisions. > > > >I look forward to your comments on these proposals. -- Nathaniel > > > > > > > > From owner-ietf-calendar@mail.imc.org Sun Nov 16 15:53:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07509 for ; Sun, 16 Nov 2003 15:53:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAGKfGkT012323 for ; Sun, 16 Nov 2003 12:41:16 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAGKfGUH012322 for ietf-calendar-bks; Sun, 16 Nov 2003 12:41:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAGKfDkT012317 for ; Sun, 16 Nov 2003 12:41:15 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:oKeSVoyQBN4J78TmcyPBff0I/ElBH9YX@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAGKfCa9005086 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 16 Nov 2003 12:41:13 -0800 Message-ID: <3FB7E0E8.50301@Royer.com> Date: Sun, 16 Nov 2003 13:41:12 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: The w3c test objects. References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020208090405010903020302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020208090405010903020302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Libby Miller wrote: > >You can find our sample iCalendar files and the derived RDF files here: > >http://www.w3.org/2002/12/cal/test/ >http://www.w3.org/2002/12/cal/ > > (A) I have seen these before. Some minor nits: Many of the VALARMs have an ATTACH property that is not valid: ATTACH;VALUE=URI:Ping Extra CR LF's in them between components. Some have no METHOD property - does that mean they are booked like in CAP? Some VEVENTs have no SUBJECT or DESCRIPTION. (B) RDF issues I have noticed in the examples: I noticed that the RDF format drops the 'VALUE' parameter completely. The RDF-cal has a 'class' tag, that is not the same as the iCAL 'class' tag. The examples drop the CLASS property nd its PUBLIC, PRIVATE, and CONFIDENTIAL values completely. The RDF-cal does not distinguish between property values and parameters. I have yet to see an example of how multivalued values are treated. Is the XML tag replicated or is the value just put in 'as is'? (C) And there is an xCAL mailing list with low volume. It has not been used in a while but the archives are online. To subscribe send email to 'majordomo@inet-consulting.com' with a subject of 'subscribe xcal-dev'. Archives at: http://inet-consulting.com/xcal-dev -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020208090405010903020302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTE2MjA0MTEyWjAjBgkqhkiG9w0BCQQxFgQUZJsh5iKUx+olGPFzke7Y ZNiqeTswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA0FYR86gkVJ3KczDo8OH8lop3QOp3sWI4HH6CzQteibJG3rjm8Yl5IJsYbfujKHR+ XfjxQNT0cFXgAfs6+mtAlAFAdSdcT6/7sMTheUVOXwtKtPO6E4RU9N9SyyMH/yvl/+5J+2Ag CbPPI4OQIufvy/h9NaLA51eul0oIzYe8Gxuz5VwhqMsG5enG+zF28Cr6ay0ENOzJJdPB7Lcl RYdU7yUSBahF2qoJ8jCvuFTfDwATngV1NyRIo7Osq4oS3hs9qEdQqm2S/tZyDSW5mbXPTTvI TJHpaAvqLF12ASCseBfSerahIBhgJ5ZbViCWeBqM8lZJMUoZOa9dyFK20573hwAAAAAAAA== --------------ms020208090405010903020302-- From owner-ietf-calendar@mail.imc.org Mon Nov 17 09:18:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12470 for ; Mon, 17 Nov 2003 09:18:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHDuNkT026839 for ; Mon, 17 Nov 2003 05:56:23 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHDuNx4026838 for ietf-calendar-bks; Mon, 17 Nov 2003 05:56:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAHDuKkT026827 for ; Mon, 17 Nov 2003 05:56:21 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003111709114213316 for ; Mon, 17 Nov 2003 09:11:44 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Nov 2003 08:53:21 -0500 Message-ID: <3FB8D2D0.9070702@centive.com> Date: Mon, 17 Nov 2003 08:53:20 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2003 13:53:21.0523 (UTC) FILETIME=[29962C30:01C3AD12] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tim Hare wrote: > I will have to look up what WebDAV is, but the rest of it sounds OK to me. RFC-2518; http://www.webdav.org It's a set of extensions to HTTP to manipulate resources on an HTTP server: move them around, create/delete them, list/create/delete directories, set/get metadata. There is also work on extending WebDAV to support versioning and searching. -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |A successful tool is one that was used to do something undreamed| |of by its author. | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 17 13:51:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27950 for ; Mon, 17 Nov 2003 13:51:53 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHIX1kT041832 for ; Mon, 17 Nov 2003 10:33:01 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHIX0gG041831 for ietf-calendar-bks; Mon, 17 Nov 2003 10:33:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHIWwkT041825 for ; Mon, 17 Nov 2003 10:32:59 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hAHIMPEG031171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2003 13:22:25 -0500 Date: Mon, 17 Nov 2003 13:33:06 -0500 From: Cyrus Daboo To: John Stracke , ietf-calendar@imc.org Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 Message-ID: <2147483647.1069075986@[10.0.1.8]> In-Reply-To: <3FB8D2D0.9070702@centive.com> References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> <3FB8D2D0.9070702@centive.com> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi John, --On Monday, November 17, 2003 8:53 -0500 John Stracke wrote: |> I will have to look up what WebDAV is, but the rest of it sounds OK to |> me. | | RFC-2518; http://www.webdav.org | | It's a set of extensions to HTTP to manipulate resources on an HTTP | server: move them around, create/delete them, list/create/delete | directories, set/get metadata. There is also work on extending WebDAV to | support versioning and searching. Access control is also an extension - obviously that would be important for any shared calendar applications. There is also an HTTP SASL extension in the works which will add more robust authentication - probably important for enterprise calendaring use. -- Cyrus Daboo From owner-ietf-calendar@mail.imc.org Tue Nov 18 16:17:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16898 for ; Tue, 18 Nov 2003 16:17:41 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIKkBkT081232 for ; Tue, 18 Nov 2003 12:46:11 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIKkBXh081231 for ietf-calendar-bks; Tue, 18 Nov 2003 12:46:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIKkAkT081226 for ; Tue, 18 Nov 2003 12:46:10 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:6Q8rvRcZ+3upPtkUsKzdZvxbrakHZ1Sz@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAIKjxa9031925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Nov 2003 12:46:01 -0800 Message-ID: <3FBA8506.8020505@Royer.com> Date: Tue, 18 Nov 2003 13:45:58 -0700 From: Doug Royer Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Hare CC: ietf-calendar@imc.org Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040109050501090704010806" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040109050501090704010806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There is a great book on WebDAV. "WebDAV: Next-Generation Collaborative Web Authoring" It gives a great review of HTTP and explains WebDAV in detail. Lisa Dusseault is the author. Tim Hare wrote: > > I will have to look up what WebDAV is, but the rest of it sounds OK to > me. ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040109050501090704010806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTE4MjA0NTU4WjAjBgkqhkiG9w0BCQQxFgQUaZOex4F9BTImhWmbRqoO JLDzfa8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEADgwNyugNnJ1vlcLp3NuO5d6Pm1q7U58Kq1FOfz5wfqpMzQVNmIsnK4OIGlXi3oM8 /uKqxAbd8ivEqSEpRPMZvl/und5clqw70YLxmyQgIs7i+OdxE5pTUHdQnw5lNjkhOzziFWuE 1U1LESeDvqjyiy54OPorK0lshpZTYBnrmn+h05J+jVHTOhpPjFiERTxClVFDTwGwz6GF7chc KgCtUciRmwXIVAE1BXJKQONrWQRAXnPrHHiLh79QyaaKUO4me2dQD6sFbXzU7BSQJCRaNbqr wG/kznqWwdRDt3fBivvFmp/Vh2b1l4rPFPwDWg3OP3lf4X4FHs2LhAWtKQkTLAAAAAAAAA== --------------ms040109050501090704010806-- From owner-ietf-calendar@mail.imc.org Wed Nov 19 12:59:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29803 for ; Wed, 19 Nov 2003 12:59:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJHZTkT003082 for ; Wed, 19 Nov 2003 09:35:29 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJHZTXf003081 for ietf-calendar-bks; Wed, 19 Nov 2003 09:35:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJHZRkT003074 for ; Wed, 19 Nov 2003 09:35:28 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:tnMLsbbfvSfYMgLB16HpDnrChfMqdAI0@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAJHZRa9011259 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 19 Nov 2003 09:35:28 -0800 Message-ID: <3FBBA9DD.9080406@Royer.com> Date: Wed, 19 Nov 2003 10:35:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050209070208090605030606" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050209070208090605030606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > 2. The Changing of the Bards: I have volunteered to perform One More > Round of edits on the CAP document, with an eye to having a Last Call > for Proposed Standard status by March. I want to express my gratitude > to Doug Royer for getting the document to the point where the remaining > problems are small enough for me to view that as an easy target date. Thanks! I am looking forward to learning from your experience. Thank you! -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050209070208090605030606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTE5MTczNTI2WjAjBgkqhkiG9w0BCQQxFgQU9IzRNazrUQhXX5cTv41N 1KVSOkQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAp9/7D5itG4txi+yin9m29ICCSLgmCJKxpksdsiNYuuGfmmMl4g5hrXw4RRUH44TR 7VDmWNj7AptJLzHR0Lkpeacbm6I8MH7IlwupegLdaqwlCi0O5QjFID+w4mTT9cgkliZLNRZw TSE+1Jh956762qUFvOHBYENXVPfm/ZkZO94dhTmvAHgZVLXAbaqnMsgEU6typbflT4AcdQG3 jX3btNBrKtT+/2RpNkY5GAdk2nn+FHP14QliizWGjkM6PnHdaXZw9GqJXQPOWs8/LeZaTlZf kyFTaee+6wYhpL1QxQ/5xYHQLQnBY42UuLdDcqi1ImqHjp8tGfumuuPdX2FdrAAAAAAAAA== --------------ms050209070208090605030606-- From owner-ietf-calendar@mail.imc.org Wed Nov 19 13:37:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02087 for ; Wed, 19 Nov 2003 13:37:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJIFfkT005352 for ; Wed, 19 Nov 2003 10:15:41 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAJIFfiB005351 for ietf-calendar-bks; Wed, 19 Nov 2003 10:15:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJIFekT005333 for ; Wed, 19 Nov 2003 10:15:40 -0800 (PST) (envelope-from george.babics@oracle.com) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAJIFaOA014211 for ; Wed, 19 Nov 2003 10:15:36 -0800 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id hAJHmNd29389 for ; Wed, 19 Nov 2003 10:48:23 -0700 (MST) Received: from oracle.com (gbabics-ca.ca.oracle.com [144.23.213.222]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id hAJHTbM12440 for ; Wed, 19 Nov 2003 10:29:37 -0700 (MST) Message-ID: <3FBBA87F.1000804@oracle.com> Date: Wed, 19 Nov 2003 12:29:35 -0500 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Report from the CALSCH WG meeting at the 58th IETF on 11/11/03 References: In-Reply-To: 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 Nathaniel Borenstein wrote: > > The CALSCH WG (really a minor fraction thereof) met in Minneapolis. > Both WG chairs and the editor of the only open document were absent > (the latter due to Jabber-related technical difficulties) from the > meeting. At the invitation of Pat Egen, I chaired the meeting. > Obviously the absence of so many key people made a major decision > inappropriate. However, there was apparent consensus for considering > several steps that we hope will reinvigorate the WG, and that we are > proposing to the mailing list for wider consideration. > > 1. The Changing of the Bobs: Bob Morgan has volunteered to come in as > WG chair in place of Bob Mahoney, who has been under increasing time > pressure and wishes to step down. Thank you Bob Mahoney for all your work. Welcome Bob Morgan. > > 2. The Changing of the Bards: I have volunteered to perform One More > Round of edits on the CAP document, with an eye to having a Last Call > for Proposed Standard status by March. I want to express my gratitude > to Doug Royer for getting the document to the point where the remaining > problems are small enough for me to view that as an easy target date. > > 3. The Changing of the Paradigms: Lisa Dusseault has volunteered to > write a first outline of what a WebDAV-enabled calendar access > mechanism might look like. > > 4. The Changing of the Version: There was general consensus that, CAP > aside, the rest of the ical documents have been around long enough and > had enough implementations that it is time to review and amend them > all. Accordingly, Bob Morgan has volunteered to draft a new charter > for the WG, and Ned Freed and Nathaniel Borenstein have both > volunteered to work on that next round of document revisions. Very good! When may the new charter be available? > > I look forward to your comments on these proposals. -- Nathaniel > I feel that these proposals are very positive and that hopefully we can finally have a last call for CAP. I would also like to add, if it is not already implicit in the above proposals, that the list, i.e., the new chair(s), should try to call a consensus on issues as soon as it is appropriate. Too often in the past, we have spent much time discussing issues or even agreeing on solutions, only to have the discussion die down without a consensus. Later the same issue would pop up again on the list, and we would often rehash the same discussion. Moreover, it will allow us to close issues and move on to other ones. George > > From owner-ietf-calendar@mail.imc.org Thu Nov 20 22:44:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15874 for ; Thu, 20 Nov 2003 22:44:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL3AlkT065854 for ; Thu, 20 Nov 2003 19:10:49 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAL3Alx6065853 for ietf-calendar-bks; Thu, 20 Nov 2003 19:10:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL3AkkT065846 for ; Thu, 20 Nov 2003 19:10:46 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (rwcrmhc11) with SMTP id <2003112103104301300mmfoie> (Authid: TimHare); Fri, 21 Nov 2003 03:10:43 +0000 Message-Id: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 20 Nov 2003 22:03:41 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: list of items In-Reply-To: <3FBBA9DD.9080406@Royer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think now is a good opportunity to take a quick vote or survey to determine what are the critical unresolved issues remaining to get the first version out the door, and what are the not-so-critical issues that we may or may not want to resolve before last call. As I am a relative latecomer to the list, I cannot yet come up with an exhaustive list, but here are a few, others can add theirs. Please - let us just list items for now without emotion behind them, we need a list, not another argument (and I _know_ some of these may still be controversial) Critical: A. Consensus that the original author's interpretation of recurrence-ID handling (quoted here) is or is not what should happen. >"3) Considerable discussion was held on semantics and behavior of recurring events during the IETF deliberations leading to WG >consensus around the definition of iCalendar. It is our belief that the intent of this consensus is as follows: >a) the value for RECURRENCE-ID was agreed to be the date/time value of the original recurrence instance. This value remains >unchanged for as long as the base recurrence set (or pattern) exists. A rescheduling of an individual recurrence instance did not >cause creation of new base recurrence set, but only moved the start/end of the specified recurrence instance. >b) An addition of a new recurrence instance to the set would be an example of an action that would create a new recurrence set >e.g. changing a Monday weekly meeting to a Monday and Tuesday weekly meeting. This latter action is an example of an action >that *might* also cause the values of the RECURRENCE-ID properties for each member of the recurrence set to get redefined >(*might* is used here and in the RFC because it is possible that occurrences in the new recurrence set will have the same >date/time value). But a rescheduling of a member of the recurrence set would not cause such behavior (i.e., change the value) of the RECURRENCE-ID property associated with the rescheduled recurrence instance. B. Whether or not a unique ID is needed to tell local alarms from non-local alarms (and whether this ID will be called ALARMID or SEQUENCE) C. Whether the CAP version will be a numeric version as in iCalendar or a list of supported RFCs. D. Consensus about whether stored queries should be retained as part of CAP or not (and if so clarity about how they work) Not-so-critical A. Whether CALSCALE should be a required property returned in response to a GET-CAPABILITY command or not B. Consensus and clarity in the document about what is returned to a VQUERY with EXPAND=TRUE for a recurrence set: the occurrences within the date range of the query, or an attempt to return all the ocurrences. OK - that's my list. If we can all post a short list of items, and merge them together, the scope of what needs to be done will be defined, and we can help get this finished. Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Thu Nov 20 22:48:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15923 for ; Thu, 20 Nov 2003 22:48:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL3U6kT066517 for ; Thu, 20 Nov 2003 19:30:06 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAL3U6Ad066516 for ietf-calendar-bks; Thu, 20 Nov 2003 19:30:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL3U5kT066501 for ; Thu, 20 Nov 2003 19:30:05 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc12) with SMTP id <2003112103300201200i922he> (Authid: TimHare); Fri, 21 Nov 2003 03:30:02 +0000 Message-Id: <5.2.1.1.0.20031120220448.00a427b0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 20 Nov 2003 22:22:57 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: an idea as an alternative to stored queries In-Reply-To: <3FBBA9DD.9080406@Royer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This may have been thought of before, but what if we defined a _small_ set of commands for the most frequently used queries, documented how they would work in the protocol, and required them to be supported? My proposals: GET-TODAY: returns all VEVENTS, VTODOS, VJOURNAL entries for the current date, expands anything which recurs within the current day; i.e. a "snapshot" of the current days VCALENDAR entries. GET-NEXT: returns next VEVENT whose beginning is after the current date/time (or, alternatively, a date/time can be passed and the next VEVENT after that will be returned). If a current date/time is within a VEVENT's DTSTART/DTEND range, how would we return that. PUT-VJOURNAL: create a VJOURNAL event for the current date/time with the text passed. There may of course be others, these three are those I would use myself off the top of my head. I believe this solves the problem for small-footprint CUAs, with little memory, (if such devices still exist by the time we get CAP out ) better than the stored queries method. The CUA only needs to send the command - the variables, which in most cases are date or date/time values, are implicitly defined from the clock of the responding CUA/CS. This also eliminates the issues of network traffic since the CUA doesn't have to send a command to find the query, retrieve that query, modify it, and then send it as a series of commands. The CUA just has to send one of the commands, and the desired results are returned. If this proposal is accepted, my belief is that we should concurrently drop the idea of stored queries as it now exists. Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Thu Nov 20 22:53:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16041 for ; Thu, 20 Nov 2003 22:53:41 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL3ZFkT066700 for ; Thu, 20 Nov 2003 19:35:15 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAL3ZFo3066698 for ietf-calendar-bks; Thu, 20 Nov 2003 19:35:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAL3ZDkT066682 for ; Thu, 20 Nov 2003 19:35:14 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc11) with SMTP id <20031121033511011001b93ee> (Authid: TimHare); Fri, 21 Nov 2003 03:35:11 +0000 Message-Id: <5.2.1.1.0.20031120222259.00a421c0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 20 Nov 2003 22:28:08 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: a question on VJOURNAL in RFC2445 In-Reply-To: <3FBBA9DD.9080406@Royer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In RCF2445 under "4.6.3 Journal Component" it states: >Description: A "VJOURNAL" calendar component is a grouping of > component properties that represent one or more descriptive text > notes associated with a particular calendar date. The "DTSTART" > property is used to specify the calendar date that the journal entry > is associated with Yet, DTSTART is not a _required_ property of a VJOURNAL entry. This seems to me to be an error in RFC2445 - can someone give me a use case or other reason for an undated VJOURNAL entry? Thanks Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Fri Nov 21 14:55:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28675 for ; Fri, 21 Nov 2003 14:55:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALJWEkT080365 for ; Fri, 21 Nov 2003 11:32:14 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALJWEAX080364 for ietf-calendar-bks; Fri, 21 Nov 2003 11:32:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALJWDkT080359 for ; Fri, 21 Nov 2003 11:32:13 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:WFsrTk3GTHeQp4M8utMtJ5dJdbl2l2kO@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hALJWBa9007612 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Nov 2003 11:32:13 -0800 Message-ID: <3FBE683A.4070000@Royer.com> Date: Fri, 21 Nov 2003 12:32:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: list of items (recur-id is not CAP) References: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060401030903090605030509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060401030903090605030509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > Critical: > A. Consensus that the original author's interpretation of > recurrence-ID handling (quoted here) is or is not what should happen. This is an iTIP (or iCAL) issue, not a CAP issue. Although it will effect the code in an implementation it will not effect the CAP protocol. It needs to be moved from the CAP issue list to the iTIP-next (or iCAL-next) issue list. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060401030903090605030509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTIxMTkzMjEwWjAjBgkqhkiG9w0BCQQxFgQU04f8WZv118NKxXgQqFnw xzjehpowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAkfkkURSUOYCBWmj4TangW8PlCNvkqobKf+ZeUgWquBmdBGPU5HIGi6GH15J5xr7u XOC4y5lukW6+WBegnLr+AaVeulARKZX2enaPhaX7k9JbYLvsb4IPX/N60j3CCu8vZB8G/gvE MmTEQyeggBTDQ/nHeklcCNyhttzP4wy8qXyba1YOw9+AI7OBS4sUhDCAcdZJdsqWN7a+C7A/ yqyIo21cgBBpLAUVKPvM0wKLFXRdwr8miuzMc8SZNhKcIhg+9nXmR1OQFNycYLEqL681MgoX zsR1ZNmZzEnp8Q3GpXggd/4WYBKUQmscq78okWMx8pHDT59AOSUhYkxhVXFy2gAAAAAAAA== --------------ms060401030903090605030509-- From owner-ietf-calendar@mail.imc.org Fri Nov 21 14:58:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28749 for ; Fri, 21 Nov 2003 14:58:54 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALJcckT080595 for ; Fri, 21 Nov 2003 11:38:38 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALJccqr080594 for ietf-calendar-bks; Fri, 21 Nov 2003 11:38:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALJcakT080587 for ; Fri, 21 Nov 2003 11:38:36 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:J24kVhCL3zK5cpqWBJrM9cKN+JaekEwc@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hALJcaa9007662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Nov 2003 11:38:37 -0800 Message-ID: <3FBE69BB.7090705@Royer.com> Date: Fri, 21 Nov 2003 12:38:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: a question on VJOURNAL in RFC2445 References: <5.2.1.1.0.20031120222259.00a421c0@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031120222259.00a421c0@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020601080601000804020805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020601080601000804020805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit RFC2446 specifies that DTSTART is required in PUBLISH and ADD. It is not needed in CANCEL. And those are the only three supported METHOD's. 'dtstart' is not listed as required in the 2445 ABNF because it is not always needed (METHOD:CANCEL). Tim Hare wrote: > > In RCF2445 under "4.6.3 Journal Component" it states: > > > >Description: A "VJOURNAL" calendar component is a grouping of > > component properties that represent one or more descriptive text > > notes associated with a particular calendar date. The "DTSTART" > > property is used to specify the calendar date that the journal entry > > is associated with > > Yet, DTSTART is not a _required_ property of a VJOURNAL entry. This > seems to me to be an error in RFC2445 - can someone give me a use case > or other reason for an undated VJOURNAL entry? > > Thanks > Tim Hare > Interested Bystander, Non-Inc. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020601080601000804020805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTIxMTkzODM1WjAjBgkqhkiG9w0BCQQxFgQUQ+c3+TSpQRTIwGRAQvSg Uwygtu4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAhsWdg9EnmL8iJi+mq4VzqmD6qgfbMTqsAxH5pxU4xut9jt/OLQHG1H+9Uq/bHKXv 3xpfxXPD6cvif7zSIN7ns9x58uW1vnf5JiBHJSWbHf/Od0QYc0/kzLqug+8YhjNfHfW3bznc CoPMK3AUwRv9fcVp3PnGoL/OBdRBZHOiAyfgufa3mMbW+KVqrtn+wMN2WQ7CfXm/SI9m1PbE aF+nW7T/yJDuldGFKxHpMBYjLTbgIWvm5JbbIsUIgTYvs2KLyJti1UzKnkSl+Cg4PkeVKA0u iaubIyKSILAliWMfhgFHEY2FfJVvUnsqEDoEOrGovcMeTpZ+JaZKDAFJUptVmAAAAAAAAA== --------------ms020601080601000804020805-- From owner-ietf-calendar@mail.imc.org Fri Nov 21 15:09:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29792 for ; Fri, 21 Nov 2003 15:09:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALJiokT080882 for ; Fri, 21 Nov 2003 11:44:50 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALJioPJ080881 for ietf-calendar-bks; Fri, 21 Nov 2003 11:44:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALJinkT080873 for ; Fri, 21 Nov 2003 11:44:49 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (rwcrmhc12) with SMTP id <2003112119444501400osvlse> (Authid: TimHare); Fri, 21 Nov 2003 19:44:45 +0000 Message-Id: <5.2.1.1.0.20031121143714.00a3d730@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 21 Nov 2003 14:37:37 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: list of items (recur-id is not CAP) In-Reply-To: <3FBE683A.4070000@Royer.com> References: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Agreed - I lost track of which discussion thread it was in. At 12:32 PM 11/21/03 -0700, you wrote: >Tim Hare wrote: > >>Critical: >> A. Consensus that the original author's interpretation of >> recurrence-ID handling (quoted here) is or is not what should happen. > > >This is an iTIP (or iCAL) issue, not a CAP issue. Although it will effect >the code in >an implementation it will not effect the CAP protocol. > >It needs to be moved from the CAP issue list to the iTIP-next (or >iCAL-next) issue list. > >-- > >Doug Royer | http://INET-Consulting.com >-------------------------------|----------------------------- >Doug@Royer.com | Office: (208)520-4044 >http://Royer.com/People/Doug | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > > > From owner-ietf-calendar@mail.imc.org Fri Nov 21 19:21:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13452 for ; Fri, 21 Nov 2003 19:21:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALNwbkT091098 for ; Fri, 21 Nov 2003 15:58:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hALNwbIJ091097 for ietf-calendar-bks; Fri, 21 Nov 2003 15:58:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hALNwZkT091091 for ; Fri, 21 Nov 2003 15:58:36 -0800 (PST) (envelope-from Libby.Miller@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Fri, 21 Nov 2003 23:58:32 +0000 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 1ANL6j-0006XQ-00; Fri, 21 Nov 2003 23:54:37 +0000 Date: Fri, 21 Nov 2003 23:54:36 +0000 (GMT) From: Libby Miller X-X-Sender: ecemm@mail.ilrt.bris.ac.uk To: ietf-calendar@imc.org cc: www-rdf-calendar@w3.org Subject: Re: The w3c test objects. In-Reply-To: <3FB7E0E8.50301@Royer.com> Message-ID: References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> <3FB7E0E8.50301@Royer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (cross-posted for info - please don't reply to both lists, thanks) On Sun, 16 Nov 2003, Doug Royer wrote: > > > Libby Miller wrote: > > > > >You can find our sample iCalendar files and the derived RDF files here: > > > >http://www.w3.org/2002/12/cal/test/ > >http://www.w3.org/2002/12/cal/ > > > > Thanks for having a look at these Doug. > (A) I have seen these before. Some minor nits: > > Many of the VALARMs have an ATTACH property that is not valid: > > ATTACH;VALUE=URI:Ping > > Extra CR LF's in them between components. Sorry, could you clarify? the ics files in that directory are all generated from tools which export iCalendar. > > Some have no METHOD property - does that mean they are booked > like in CAP? I'll have to look into that. > > Some VEVENTs have no SUBJECT or DESCRIPTION. > Descriptions and summaries are optional, as I understand it - is that incorrect? > (B) RDF issues I have noticed in the examples: > > I noticed that the RDF format drops the 'VALUE' parameter completely. > VALUE (as in VALUE=BINARY, VALUE=DATE) is handled in various ways within the RDF model. So in RDF whether something is text or a uri is a crucial distinction handled by the RDF syntax. Whether something is a DATE or a DATETIME is handled using different RDF properties. I think the main thing is that we can roundtrip between the RDF and iCalendar versions, so we aren't losing information - inevitably there will be differences in the syntactic representation that are difficult to explain as we are translating between two different representational languages. > The RDF-cal has a 'class' tag, that is not the same as the iCAL > 'class' tag. > hm, it's not intended to be different. All we have done is create uris to represent the possible values for class, i.e. public, private, confidential become etc this just fits in better with the way RDF works - it's much better at matching URIs than strings. > The examples drop the CLASS property nd its PUBLIC, PRIVATE, > and CONFIDENTIAL values completely. > > The RDF-cal does not distinguish between property values and parameters. this distinction doesn't really matter to RDF :) We don't think that matters as long as we can get back to the iCalendar format as required. > > I have yet to see an example of how multivalued values are treated. > Is the XML tag replicated or is the value just put in 'as is'? Which properties were you thinking of? If there were (say) two descriptions then you would just repeat the tag. I don't think we have come across any iCalendar data with repeated tags yet. RDF has an underlying model of object->property->object, so the syntax would depend on whether the repeated tag translated into an RDF object or property. > > (C) And there is an xCAL mailing list with low volume. It has not been used > in a while but the archives are online. > > To subscribe send email to 'majordomo@inet-consulting.com' with > a subject of 'subscribe xcal-dev'. thanks, will do. > > Archives at: http://inet-consulting.com/xcal-dev > > Thanks again for taking a look at what we've been doing - it's very useful to get such detailed feedback from the iCalendar community. Libby From owner-ietf-calendar@mail.imc.org Fri Nov 21 20:10:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14648 for ; Fri, 21 Nov 2003 20:10:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM0jCkT092783 for ; Fri, 21 Nov 2003 16:45:12 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAM0jCJw092782 for ietf-calendar-bks; Fri, 21 Nov 2003 16:45:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAM0jAkT092776 for ; Fri, 21 Nov 2003 16:45:11 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:t/JjMDZckvJBYDKVnEtsE+a3UqBaROtn@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAM0j9a9010580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Nov 2003 16:45:10 -0800 Message-ID: <3FBEB195.7060501@Royer.com> Date: Fri, 21 Nov 2003 17:45:09 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: The w3c test objects. References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> <3FB7E0E8.50301@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050404060308040602010100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050404060308040602010100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Libby Miller wrote: > > > >>(A) I have seen these before. Some minor nits: >> >> Many of the VALARMs have an ATTACH property that is not valid: >> >> ATTACH;VALUE=URI:Ping >> >> Extra CR LF's in them between components. >> >> > >Sorry, could you clarify? the ics files in that directory are all >generated from tools which export iCalendar. > Nothing serious, but several of the components end with: CR LF CR LF and not just CR LF I do not know of a parser that can not handle it, but it is not per the 2445 ABNF. >> Some VEVENTs have no SUBJECT or DESCRIPTION. >> >> >> > >Descriptions and summaries are optional, as I understand it - is that >incorrect? > Yes incorrect. When they have the METHOD property for example. See the restriction tables in RFC-2447. For example SUMMARY in a VEVENT PUBLISH is not optional, but may be empty. >(B) RDF issues I have noticed in the examples: > > I noticed that the RDF format drops the 'VALUE' parameter completely. > >VALUE (as in VALUE=BINARY, VALUE=DATE) is handled in various ways within >the RDF model. >So in RDF whether something is text or a uri is a crucial distinction >handled by the RDF syntax. Whether something is a DATE or a DATETIME is >handled using different RDF properties. > >I think the main thing is that we can roundtrip between the RDF and >iCalendar versions, so we aren't losing information - inevitably there >will be differences in the syntactic representation that are difficult >to explain as we are translating between two different representational >languages. > > How do you handle VALUE=x-user-type ? Example: iCAL: x-foo-property;VALUE=x-user-type:1234 RDF: ? > The RDF-cal has a 'class' tag, that is not the same as the iCAL >'class' tag. > >hm, it's not intended to be different. All we have done is create uris >to represent the possible values for class, i.e. public, private, >confidential become > > > >etc > >this just fits in better with the way RDF works - it's much better at >matching URIs than strings. > Okay, perhaps because it looked different from the way the other property values were translated I may have missed it. Looking closer... As it appears that the URL specified is specific to iCAL, why is CLASS treated as a special property type? > The examples drop the CLASS property nd its PUBLIC, PRIVATE, > and CONFIDENTIAL values completely. > > The RDF-cal does not distinguish between property values and parameters. > > > >this distinction doesn't really matter to RDF :) >We don't think that matters as long as we can get back to the iCalendar >format as required. > Maybe ... still thinking about this. > > >> I have yet to see an example of how multivalued values are treated. >> Is the XML tag replicated or is the value just put in 'as is'? >> >> > >Which properties were you thinking of? If there were (say) two >descriptions then you would just repeat the tag. I don't think we have >come across any iCalendar data with repeated tags yet. RDF has an >underlying model of object->property->object, so the syntax would >depend on whether the repeated tag translated into an RDF object or >property. > Multi valued means two or more values for ONE property, not the same property repeated twice. CATAGORIES for example allows one or more values separated by a comma. This example is one property with two valules: CATEGORIES:BUSINESS,HUMAN RESOURCES >Thanks again for taking a look at what we've been doing - it's very >useful to get such detailed feedback from the iCalendar community. > And again I think that any WebDAV work should be separate from a specification on translation of date from iCAL from and to XML. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050404060308040602010100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTIyMDA0NTA5WjAjBgkqhkiG9w0BCQQxFgQUkdbSjLWxmuM6gHuEM6VS 8qkOHcUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAv1d1Y5WYqQu6lnCM4O4avEofLg4yVIe7XU6Q0eKdzVdT91CZVYUg72hW4UFyVw5b sVAKSPTAMdZX+ZO0+JDtJhTsPg6/Ju+Y2edHH9sRtmUuIUnJYwb8UeTxZRPV7BzkMj3Nws/i bTKepVT3fbmpfNyHTupO3hkTJwnC2vmG/E8wz/5wp6mk+TFyvdbtu0bQweKcU6g1Wf0xd4KL wUwkxO+n66SNJIwBSxlRyY4W/J4qacrucqixcVUFuXVSg/fFuL92B/Xh6ylVg8FouC42QyMG fUJc+cw6NxcpUVKbHo0FgtGfdkE3eqqe2oIju8b8sUxeDvLSrGnhs4v2+akkqAAAAAAAAA== --------------ms050404060308040602010100-- From owner-ietf-calendar@mail.imc.org Sun Nov 23 20:41:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07071 for ; Sun, 23 Nov 2003 20:41:39 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAO1JckT043161 for ; Sun, 23 Nov 2003 17:19:38 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAO1JcEr043160 for ietf-calendar-bks; Sun, 23 Nov 2003 17:19:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAO1JakT043153 for ; Sun, 23 Nov 2003 17:19:37 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:pE5KVXqBLJalts6U9J2Yf3ArSTnArq9M@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAO1JaaM026335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 23 Nov 2003 17:19:38 -0800 Message-ID: <3FC15CA8.9060701@Royer.com> Date: Sun, 23 Nov 2003 18:19:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: list of items (VALARM id) References: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010301030104020000050600" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010301030104020000050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > > B. Whether or not a unique ID is needed to tell local alarms > from non-local alarms (and whether this ID will be called ALARMID or > SEQUENCE) The issues is not local/non-local. The issue is the ability to uniquely identify VALARMS within a component. And if VALARM will be the only component without a unique id. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010301030104020000050600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI0MDExOTM2WjAjBgkqhkiG9w0BCQQxFgQU7CRx1XY3SKIImWkOQ/7T jqO8OgYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAZZPA3YOzi7cD4TJKQUY4i7pSZIxgeRcV1YRClJZRc56ntnESuDReXk3p1z6/5Iq6 2LJLl+VaKWN+jGkCI8g3vz/S+1FhrYWkm7Svxk59zYAIMdPIet9DfwHNLduWgPKcU2TBdhKy eGniXPIfe3+5DT+Qfahz6D5nx/zJMWokDLrt2qvToti8rRCHPguIDgnwdC5iAyKnVF6ZamRu b3ajy1qtZ8BLGfzNZkzfYjKSqoTRDeLtDO37NaTUJF/YWcLTkol9RK6AQLjN7ocx4CwTI/eV K9Ku003/JEUMC34YOcSpfWzsSVIzECNxpI0il26z2r0rfUL0IwFh53GpeKZkrwAAAAAAAA== --------------ms010301030104020000050600-- From owner-ietf-calendar@mail.imc.org Mon Nov 24 09:57:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10311 for ; Mon, 24 Nov 2003 09:57:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOERYkT045551 for ; Mon, 24 Nov 2003 06:27:34 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOERYZk045550 for ietf-calendar-bks; Mon, 24 Nov 2003 06:27:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAOERWkT045542 for ; Mon, 24 Nov 2003 06:27:33 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003112409425421477 ; Mon, 24 Nov 2003 09:42:54 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Nov 2003 09:24:30 -0500 Message-ID: <3FC2149E.1060502@centive.com> Date: Mon, 24 Nov 2003 09:24:30 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Libby Miller CC: ietf-calendar@imc.org Subject: Re: The w3c test objects. References: <5.2.1.1.0.20031115211041.00a24710@mail.comcast.net> <3FB7E0E8.50301@Royer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2003 14:24:30.0522 (UTC) FILETIME=[AC7D09A0:01C3B296] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Libby Miller wrote: >> The RDF-cal does not distinguish between property values and parameters. >> >> > >this distinction doesn't really matter to RDF :) >We don't think that matters as long as we can get back to the iCalendar >format as required. > That's incorrect. You need to build an isomorphism between iCalendar and RDF, *not* between "iCalendar with the properties and parameters defined in RFC-2445" and RDF. You're not the first to make this mistake; the xCal spec had the same problem (maybe it still does; not sure). It's an easy mistake to make, since RFC-2445 comingles the data model with the low-level syntax. But the guideline you need to adopt is that your definition of the mapping MUST NOT know anything about individual components, properties, or parameters; it MUST be able to handle any legal iCalendar object, even if it uses entities which aren't defined today. Suppose two people have iCalendar-based CUAs, but there's an RDF store somewhere along the path between them; when an iCalendar object reaches that RDF store, and later gets extracted, the resulting iCalendar must be equivalent to the original. Perhaps 2445bis should be split into two documents, one to define the syntax and one to define the data model (as was done with vCard; see RFC-242[56]). -- /=====================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=====================================================| |"The Reality Check's in the mail." --L. Peter Deutsch| \=====================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 24 13:14:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19654 for ; Mon, 24 Nov 2003 13:14:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOHpIkT055460 for ; Mon, 24 Nov 2003 09:51:18 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOHpILe055459 for ietf-calendar-bks; Mon, 24 Nov 2003 09:51:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOHpHkT055451 for ; Mon, 24 Nov 2003 09:51:17 -0800 (PST) (envelope-from vicky.oliver@Sun.COM) Received: from phys-ha13sca-1 ([129.145.155.91]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAOHpIPh001415 for ; Mon, 24 Nov 2003 10:51:18 -0700 (MST) Received: from harukk.red.iplanet.com (harukk.red.iplanet.com [192.18.146.62]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HOV00GX5AXI55@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Mon, 24 Nov 2003 09:51:18 -0800 (PST) Date: Mon, 24 Nov 2003 09:52:40 -0800 From: "V. Oliver" Subject: Clarification for Free/Busy To: ietf-calendar@imc.org Message-id: <0HOV00GX6AXI55@ha13sca-mail1.sfbay.sun.com> MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="5789334-620-1069696361=:1776" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --5789334-620-1069696361=:1776 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE I am hoping that someone can clarify how to map from a VEVENT component's p= roperties to what should be returned for a Free/Busy request.=20 =A0 RFC 2445 states unambiguously that TRANSP is the property that is to be use= d to return Free/Busy status. From "4.8.2.7 Time Transparency": =A0 Description: Time Transparency is the characteristic of an event that =A0=A0 determines whether it appears to consume time on a calendar. Events =A0=A0 that consume actual time for the individual or resource associated =A0=A0 with the calendar SHOULD be recorded as OPAQUE, allowing them to be =A0=A0 detected by free-busy time searches. Other events, which do not take =A0=A0 up the individual's (or resource's) time SHOULD be recorded as =A0=A0 TRANSPARENT, making them invisible to free-busy time searches. =A0 This seems clear until I read the description of the free busy time type pa= rameter, FBTYPE (a parameter of FREEBUSY, which is a property of a VFREEBUS= Y component). From "4.2.9 Free/Busy Time Type" (fbtype): =A0 Description: The parameter specifies the free or busy time type. The =A0=A0 value FREE indicates that the time interval is free for scheduling. =A0=A0 The value BUSY indicates that the time interval is busy because one =A0=A0 or more events have been scheduled for that interval. The value =A0=A0 BUSY-UNAVAILABLE indicates that the time interval is busy and that =A0=A0 the interval can not be scheduled. The value BUSY-TENTATIVE indicate= s =A0=A0 that the time interval is busy because one or more events have been =A0=A0 tentatively scheduled for that interval. If not specified on a =A0=A0 property that allows this parameter, the default is BUSY. =A0 The above clearly states that there are four (4) levels of free/busy: =A0 FREE=20 BUSY BUSY-UNAVAILABLE=20 BUSY-TENTATIVE =A0 What I'm missing is a way to map from an Event's TRANSP property which has = only two states (FREE or BUSY) to these four states.=20 =A0 Is the intention that free/busy should be reported by combining TRANSP with= some other property or properties? If I just look at the value "tentative"= , I see that there are actually two places in an Event where I could potent= ially derive that value: PARTSTAT and STATUS. I don't see any explicit inst= ruction in RFC 2445 for this. =A0 Let me rephrase this a bit in the hope of getting a more exact answer. And = instead of looking at a VEVENT and deciding what the FBTYPE should be, can = we look at what the desired FBTYPE is and work backwards? =A0 What does the VEVENT look like that would generate, for example, the follow= ing property in a VFREEBUSY component: =A0 FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20031201T130000Z/20031201T140000Z =A0 or to get even more explicit let's take several cases: =A0 1. An attendee has been invited to an event and replied with a tentative ac= ceptance. What does the Attendee's copy of that VEVENT look like in order t= o return=20 =A0FREEBUSY;FBTYPE=3DBUSY-TENTATIVE: =A0 2. An attendee has been invited to an event and replied with a decline. If = the attendee retains that event (maybe he want to be able to change his min= d later?), what does his copy of that VEVENT look like? I assume that he sh= ould report that timeslot as being "FREE":=20 =A0FREEBUSY;FBTYPE=3DFREE: =A0 3. An attendee has been invited to an event and replied with an acceptance.= The organizer has then canceled the event, but the Attendee retains a copy= (for whatever reason). What does the Attendee's copy of that VEVENT look l= ike in order to return=20 =A0FREEBUSY;FBTYPE=3DFREE: =A0 4. What does anyone's (organizer or attendee) VEVENT copy look like to gene= rate: =A0FREEBUSY;FBTYPE=3DBUSY-UNAVAILABLE: =A0 In case it's not clear, I'm looking for someone to help me out by telling m= e that the associated VEVENT would look like: =A0 TRANSP: STATUS: ATTENDEE: =A0 or any appropriate fields and values that are involved. =A0 =A0 I'd appreciate any help the list can give. =A0 =A0 =A0 --5789334-620-1069696361=:1776 Content-Type: TEXT/HTML; CHARSET=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE = Message
I am hoping that someone can clarify how to ma= p from a VEVENT component's properties to what should be returned for a F= ree/Busy request.
 
RFC 2445 states unambiguously that TRANSP is t= he property that is to be used to return Free/Busy status. From "4.8.2.7 = Time Transparency":
 
Description: Time Transparency is the charac= teristic of an event that
    determines whether it appears to consume time on a calenda= r. Events
    that consume actual time for the individual or resource as= sociated
    with the calendar SHOULD be recorded as OPAQUE, allowing t= hem to be
    detected by free-busy time searches. Other events, which d= o not take
    up the individual's (or resource's) time SHOULD be recorde= d as
    TRANSPARENT, making them invisible to free-busy time searc= hes.
 

This seems clear until I read the description of the free busy time type = parameter, FBTYPE (a parameter of FREEBUSY, which is a property of a VFRE= EBUSY component). From "4.2.9 Free/Busy Time Type" (fbtype):
 
Description: The parameter specifies the free = or busy time type. The
    value FREE indicates that the time interval is free for sc= heduling.
    The value BUSY indicates that the time interval is busy be= cause one
    or more events have been scheduled for that interval. The = value
    BUSY-UNAVAILABLE indicates that the time interval is busy = and that
    the interval can not be scheduled. The value BUSY-TENTATIV= E indicates
    that the time interval is busy because one or more events = have been
    tentatively scheduled for that interval. If not specified = on a
    property that allows this parameter, the default is BUSY. =
 
The above clearly states that there are four (= 4) levels of free/busy:
 
FREE
BUSY
BUSY-UNAVAILABLE
BUSY-TENTATIVE
 
What I'm missing is a way to map from an Event= 's TRANSP property which has only two states (FREE or BUSY) to these four= states.
 
Is the intention that free/busy should be repo= rted by combining TRANSP with some other property or properties? If I jus= t look at the value "tentative", I see that there are actually two places= in an Event where I could potentially derive that value: PARTSTAT and ST= ATUS. I don't see any explicit instruction in RFC 2445 for this. =
 
Let me rephrase this a bit in the hope of gett= ing a more exact answer. And instead of looking at a VEVENT and deciding = what the FBTYPE should be, can we look at what the desired FBTYPE is and = work backwards?
 
What does the VEVENT look like that would gene= rate, for example, the following property in a VFREEBUSY component:
 
FREEBUSY;FBTYPE=3DBUSY-TENTATIVE:20031201T130= 000Z/20031201T140000Z
 
or to get even more explicit let's take severa= l cases:
 
1. An attendee has been invited to an event an= d replied with a tentative acceptance. What does the Attendee's copy of t= hat VEVENT look like in order to return
 FREEBUSY;FBTYPE=3DBUSY-TENTATIVE: <dates >
 
2. An attendee has been invited to an event an= d replied with a decline. If the attendee retains that event (maybe he wa= nt to be able to change his mind later?), what does his copy of that VEVE= NT look like? I assume that he should report that timeslot as being "FREE= ":
 FREEBUSY;FBTYPE=3DFREE: <dates >
 
3. An attendee has been invited to an event an= d replied with an acceptance. The organizer has then canceled the event, = but the Attendee retains a copy (for whatever reason). What does the Atte= ndee's copy of that VEVENT look like in order to return
 FREEBUSY;FBTYPE=3DFREE: <dates >
 
4. What does anyone's (organizer or attendee) = VEVENT copy look like to generate:
 FREEBUSY;FBTYPE=3DBUSY-UNAVAILABLE: <dates >
 

In case it's not clear, I'm looking for someone to help me out by telling= me that the associated VEVENT would look like:
 
TRANSP: <value >
STATUS: <value >
ATTENDEE: <whatever >
 
or any appropriate fields and values that are = involved.
 
 
I'd apprecia= te any help the list can give.
 
 

 
--5789334-620-1069696361=:1776-- From owner-ietf-calendar@mail.imc.org Mon Nov 24 13:23:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19841 for ; Mon, 24 Nov 2003 13:23:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOI4WkT056334 for ; Mon, 24 Nov 2003 10:04:32 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOI4WfD056333 for ietf-calendar-bks; Mon, 24 Nov 2003 10:04:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOI4WkT056328 for ; Mon, 24 Nov 2003 10:04:32 -0800 (PST) (envelope-from arnaud.quillaud@sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAOI4XPh009803 for ; Mon, 24 Nov 2003 11:04:33 -0700 (MST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAOI4IDS017407; Mon, 24 Nov 2003 10:04:18 -0800 (PST) Received: from iabs-2k.red.iplanet.com (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HOV00BAIBJKXY@mpkmail.eng.sun.com>; Mon, 24 Nov 2003 10:04:33 -0800 (PST) Date: Mon, 24 Nov 2003 10:04:38 -0800 From: Arnaud Quillaud Subject: RE: list of items (recur-id is not CAP) In-reply-to: <3FBE683A.4070000@Royer.com> To: ietf-calendar@imc.org Message-id: <0HOV00BAJBJKXY@mpkmail.eng.sun.com> MIME-version: 1.0 Content-type: APPLICATION/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-transfer-encoding: BASE64 Content-disposition: inline; filename=smime.p7m Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: BASE64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AaCAJIAEggkjQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9 Imlzby04ODU5LTEiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0 DQoNCkFjdHVhbGx5LCBpZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0 aGUgZm9sbG93aW5nIHNlY3Rpb24gb2YgQ0FQDQpzZWVtcyB0byBtYWtlIHVz ZSBvZiB0aGUgIndyb25nIiBtb2RlbCBmb3IgcmVjdXJyZW5jZS1pZDoNCjw8 DQo2LjEuMS4xNSBRdWVyeSBieSBEYXRlLVRpbWUgcmFuZ2UNCg0KICAgVGhp cyBxdWVyeSBzZWxlY3RzIHRoZSBlbnRpcmUgY29udGVudCBvZiBldmVyeSBi b29rZWQgIlZFVkVOVCINCiAgIGNvbXBvbmVudCB0aGF0IGhhcyBhbiBpbnN0 YW5jZSBncmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8gSnVseSAxc3QsDQogICAy MDAwIDAwOjAwOjAwIFVUQyBhbmQgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIEp1 bHkgMzBzdCwgMjAwMCAyMzo1OTo1OQ0KICAgVVRDLiBUaGlzIGluY2x1ZGVz IHNpbmdsZSBpbnN0YW5jZSAiVkVWRU5UIiBjb21wb25lbnRzIHRoYXQgZG8g bm8NCiAgIGV4cGxpY2l0bHkgY29udGFpbiBhbnkgcmVjdXJlbmNlIHByb3Bl cnRpZXMgb3IgIlJFQ1VSUkVOQ0UtSUQiDQogICBwcm9wZXJ0aWVzLiBUaGlz IHdvcmtzIG9ubHkgZm9yIENTcyB0aGF0IGhhdmUgdGhlICJSRUNVUi1FWFBB TkQiDQogICBwcm9wZXJ0eSB2YWx1ZSBzZXQgdG8gIlRSVUUiIGluIHRoZSAi R0VULUNBUEFCSUxJVFkiIGV4Y2hhbmdlLg0KDQogICBCRUdJTjpWUVVFUlkN CiAgIEVYUEFORDpUUlVFDQogICBRVUVSWTpTRUxFQ1QgKiBGUk9NIFZFVkVO VA0KICAgV0hFUkUgUkVDVVJSRU5DRS1JRCA+PSAnMjAwMDA3MDFUMDAwMDAw WicNCiAgIEFORCBSRUNVUlJFTkNFLUlEIDw9ICcyMDAwMDczMFQyMzU5NTla Jw0KICAgQU5EIFNUQVRFKCkgPSAnQk9PS0VEJw0KICAgRU5EOlZRVUVSWQ0K Pj4NClNpbmNlIHRoZSByZWN1cnJlbmNlLWlkIG9mIGFuIGluc3RhbmNlIG1p Z2h0IG5vdCBjb3JyZXNwb25kIHRvIGl0cw0KY3VycmVudCBkdHN0YXJ0LCB0 aGUgZXhhbXBsZSBhYm92ZSB3b24ndCBkbyB3aGF0IGl0cyBkZXNjcmlwdGlv biBzYXlzIGl0DQpzaG91bGQgZG8uDQpXaHkgY2FuJ3Qgd2UgdXNlIHRoZSBE VFNUQVJUIGZvciB0aGlzIHR5cGUgb2YgcXVlcnkgPw0KDQpJJ20gbG9va2lu ZyBhdA0KaHR0cDovL2luZXQtY29uc3VsdGluZy5jb20vZHJhZnQtaWV0Zi1j YWxzY2gtY2FwLTEyLWUudHh0LiBEb24ndCBrbm93IGlmDQp0aGlzIGlzIHRo ZSByaWdodCB2ZXJzaW9uIHRvIGxvb2sgYXQuDQoNCkFybmF1ZA0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvdWcgUm95ZXIg W21haWx0bzpEb3VnQHJveWVyLmNvbV0NCj4gU2VudDogRnJpZGF5LCBOb3Zl bWJlciAyMSwgMjAwMyAxMTozMiBBTQ0KPiBUbzogaWV0Zi1jYWxlbmRhckBp bWMub3JnDQo+IFN1YmplY3Q6IFJlOiBsaXN0IG9mIGl0ZW1zIChyZWN1ci1p ZCBpcyBub3QgQ0FQKQ0KPiANCj4gDQo+IA0KPiANCj4gVGltIEhhcmUgd3Jv dGU6DQo+IA0KPiA+IENyaXRpY2FsOg0KPiA+ICAgQS4gICAgQ29uc2Vuc3Vz IHRoYXQgdGhlIG9yaWdpbmFsIGF1dGhvcidzIGludGVycHJldGF0aW9uIG9m IA0KPiA+IHJlY3VycmVuY2UtSUQgaGFuZGxpbmcgKHF1b3RlZCBoZXJlKSBp cyBvciBpcyBub3Qgd2hhdCANCj4gc2hvdWxkIGhhcHBlbi4gDQo+IA0KPiAN Cj4gVGhpcyBpcyBhbiBpVElQIChvciBpQ0FMKSBpc3N1ZSwgbm90IGEgQ0FQ IGlzc3VlLiBBbHRob3VnaCBpdCB3aWxsIA0KPiBlZmZlY3QgdGhlIGNvZGUg aW4NCj4gYW4gaW1wbGVtZW50YXRpb24gaXQgd2lsbCBub3QgZWZmZWN0IHRo ZSBDQVAgcHJvdG9jb2wuDQo+IA0KPiBJdCBuZWVkcyB0byBiZSBtb3ZlZCBm cm9tIHRoZSBDQVAgaXNzdWUgbGlzdCB0byB0aGUgaVRJUC1uZXh0IChvciAN Cj4gaUNBTC1uZXh0KSBpc3N1ZSBsaXN0Lg0KPiANCj4gLS0gDQo+IA0KPiBE b3VnIFJveWVyICAgICAgICAgICAgICAgICAgICAgfCAgIGh0dHA6Ly9JTkVU LUNvbnN1bHRpbmcuY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRG91Z0BS b3llci5jb20gICAgICAgICAgICAgICAgIHwgT2ZmaWNlOiAoMjA4KTUyMC00 MDQ0DQo+IGh0dHA6Ly9Sb3llci5jb20vUGVvcGxlL0RvdWcgICB8ICAgIEZh eDogKDg2Nik1OTQtODU3NA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgIENlbGw6ICgyMDgpNTIwLTQwNDQNCj4gDQo+ICAgICAgICAg ICAgICAgIFdlIERvIFN0YW5kYXJkcyAtIFlvdSBOZWVkIFN0YW5kYXJkcw0K PiANCj4gDQoAAAAAAACgggoYMIICPTCCAaYCEQDNun9W8N/kvFT+IqyzcqpV MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4 MDEyMzU5NTlaMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw 0FaEGIeaBpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5F VmkfeAKA2txHkSm7NsljXMXg1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATAN BgkqhkiG9w0BAQIFAAOBgQBMP7iLxmjf7kMzDl3ppssHhE16M/+SG/Q2rdiV IjZoEWx8QszznC7EBz8UsA9P/5CSdvnivErpj82ggAr3xSnxgiJduLHdgSOj eyUVRjB5FvjqBUuUfx3CHMjjt/QQQDwTw18fU+hI5Ia0e6E1sHslurjTjqs/ OJ0ANACY89FxlDCCA2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJ KoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIz NTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3 Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77J JwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nb N2rISsgJBuSZAgMBAAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1Ud HwQuMCwwKqAooCaGJGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuMS4x LmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEW H3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB /wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/ COxNVS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJ CfK8BkL4WoyD0YreqiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp 8WjrE8R8N/SUZA2axb0zF++DM6A+5ao+rthzH60wggRpMIID0qADAgECAhBT kZelVE9wIahot8I+XDDEMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAzMTAxNzAwMDAwMFoXDTAzMTIxNjIzNTk1OVow ggENMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMScwJQYDVQQLEx5EaWdp dGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQxGDAWBgNVBAMUD0FybmF1ZCBR dWlsbGF1ZDEmMCQGCSqGSIb3DQEJARYXYXJuYXVkLnF1aWxsYXVkQHN1bi5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALwGYutijVnJhIBzDgyD nJtv6TCr+QGy3fU0jZT3sN28jBgOybYRQKZzoNPi9VykdY6R/1sUm+RDpzIe T0DpRqe53s2jdY1wzu+suZtEu7q7z45/SQBbDTB7Q+Jea/BakoCn/uxuR+Sf UuQ6O1Wf/8i9Dmn4FmFHdHb/Gcg4eLgtAgMBAAGjggEGMIIBAjAJBgNVHRME AjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjAR BglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCT eXcUAXfSvOiraHiC2UuiPuKnMnI0sVB0tXrRbiBeT7xBnkWQhub8VVUgmF5q YcXAZZPNYyRajf1Na/mMh3Mfh2toU1YWnToLyql4R3Ks6q5s/po+RYiM5GGb q7vmKcjSnAd1fOfCXnSBVkMcT2MvpQ3xP51iL7VeN6lsPV2bgzGCA1YwggNS AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBTkZelVE9wIaho t8I+XDDEMAkGBSsOAwIaBQCgggHKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyNDE4MDQzNlowIwYJKoZIhvcNAQkE MRYEFCG1/U1r6tgSU16eA1XA0yhpx/YHMHYGCSqGSIb3DQEJDzFpMGcwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqGSIb3DQIFMAoG CCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEFORl6VUT3AhqGi3wj5cMMQwDQYJKoZIhvcNAQEBBQAE gYAmNnkALH+VDw0Y9vKqk3uUD+X2WVLrUhXZi0D2vvVq+YuYYvVH6K5Dvetj +x6G50awpCO48EsplBYktImS/TPPrG0F3VKD3yJMMK2RUJrt31yO0I3+zz7L QnNYsu/ZtvlGWdeKybK7O+h9bS6TIhEUjU2FhAe40nIeNenOc9nt8QAAAAAA AA== From owner-ietf-calendar@mail.imc.org Mon Nov 24 13:24:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19890 for ; Mon, 24 Nov 2003 13:24:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOI8BkT056522 for ; Mon, 24 Nov 2003 10:08:11 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOI8B0m056521 for ietf-calendar-bks; Mon, 24 Nov 2003 10:08:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOI8AkT056514 for ; Mon, 24 Nov 2003 10:08:10 -0800 (PST) (envelope-from arnaud.quillaud@sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAOI86UP027025; Mon, 24 Nov 2003 10:08:06 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAOI7pDU018166; Mon, 24 Nov 2003 10:07:52 -0800 (PST) Received: from iabs-2k.red.iplanet.com (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HOV00BLLBPIXY@mpkmail.eng.sun.com>; Mon, 24 Nov 2003 10:08:06 -0800 (PST) Date: Mon, 24 Nov 2003 10:08:11 -0800 From: Arnaud Quillaud Subject: RE: list of items In-reply-to: <5.2.1.1.0.20031120214454.00a3caa0@mail.comcast.net> To: Tim Hare , ietf-calendar@imc.org Message-id: <0HOV00BLMBPIXY@mpkmail.eng.sun.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Was the freebusy model (responsabilities of the CS/CUA) totally clarified ? I think it would deserve a few examples. Arnaud Quillaud > -----Original Message----- > From: Tim Hare [mailto:TimHare@comcast.net] > Sent: Thursday, November 20, 2003 7:04 PM > To: ietf-calendar@imc.org > Subject: list of items > > > > I think now is a good opportunity to take a quick vote or survey to > determine what are the critical unresolved issues remaining > to get the > first version out the door, and what are the not-so-critical > issues that we > may or may not want to resolve before last call. As I am a relative > latecomer to the list, I cannot yet come up with an > exhaustive list, but > here are a few, others can add theirs. Please - let us just > list items for > now without emotion behind them, we need a list, not another > argument (and > I _know_ some of these may still be controversial) > > Critical: > A. Consensus that the original author's interpretation of > recurrence-ID > handling (quoted here) is or is not what should happen. > >"3) Considerable discussion was held on semantics and behavior > of recurring events during the IETF deliberations leading to > WG >consensus around the definition of iCalendar. It is > our belief that > the intent of this consensus is as follows: > > >a) the value for RECURRENCE-ID was agreed to be the > date/time value of > the original recurrence instance. This value remains >unchanged for > as long as the base recurrence set (or pattern) exists. A > rescheduling of > an individual recurrence instance did not >cause creation > of new base > recurrence set, but only moved the start/end of the > specified recurrence > instance. > > >b) An addition of a new recurrence instance to the set > would be > an example of an action that would create a new recurrence > set >e.g. > changing a Monday weekly meeting to a Monday and Tuesday > weekly meeting. > This latter action is an example of an action >that > *might* also cause > the values of the RECURRENCE-ID properties for each member of the > recurrence set to get redefined >(*might* is used here > and in the RFC > because it is possible that occurrences in the new > recurrence set will > have the same >date/time value). But a rescheduling > of a member of the > recurrence set would not cause such behavior (i.e., change > the value) > of the RECURRENCE-ID property associated with the > rescheduled recurrence > instance. > > B. Whether or not a unique ID is needed to tell > local alarms from > non-local alarms (and whether this ID will be called ALARMID > or SEQUENCE) > > C. Whether the CAP version will be a numeric version as in > iCalendar or > a list of supported RFCs. > > D. Consensus about whether stored queries should be > retained as part of > CAP or not (and if so clarity about how they work) > > Not-so-critical > > A. Whether CALSCALE should be a required property returned > in response > to a GET-CAPABILITY command or not > B. Consensus and clarity in the document about what is > returned to a > VQUERY with EXPAND=TRUE for a recurrence set: the occurrences > within the > date range of the query, or an attempt to return all the ocurrences. > > > OK - that's my list. If we can all post a short list of > items, and merge > them together, the scope of what needs to be done will be > defined, and we > can help get this finished. > > Tim Hare > Interested Bystander, Non-Inc. > > > From owner-ietf-calendar@mail.imc.org Mon Nov 24 16:25:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01235 for ; Mon, 24 Nov 2003 16:25:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOL4tkT066633 for ; Mon, 24 Nov 2003 13:04:55 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAOL4tNe066631 for ietf-calendar-bks; Mon, 24 Nov 2003 13:04:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOL4pkT066625 for ; Mon, 24 Nov 2003 13:04:54 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:I1QapBZxm3Fdh+gyfqMM88aa0mChQaa/@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAOL4iaM005810 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Nov 2003 13:04:52 -0800 Message-ID: <3FC2726C.9000502@Royer.com> Date: Mon, 24 Nov 2003 14:04:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Clarification for Free/Busy References: <0HOV00GX6AXI55@ha13sca-mail1.sfbay.sun.com> In-Reply-To: <0HOV00GX6AXI55@ha13sca-mail1.sfbay.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090302060108080708010306" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090302060108080708010306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit V. Oliver wrote: > I am hoping that someone can clarify how to map from a VEVENT > component's properties to what should be returned for a Free/Busy > request. > > RFC 2445 states unambiguously that TRANSP is the property that is to > be used to return Free/Busy status. From "4.8.2.7 Time Transparency": > > Description: Time Transparency is the characteristic of an event that > determines whether it appears to consume time on a calendar. Events > that consume actual time for the individual or resource associated > with the calendar SHOULD be recorded as OPAQUE, allowing them to be > detected by free-busy time searches. Other events, which do not take > up the individual's (or resource's) time SHOULD be recorded as > TRANSPARENT, making them invisible to free-busy time searches. SHOULD means you can break the rule if you want. MUST means you can not break the rule and be compliant. > This seems clear until I read the description of the free busy time > type parameter, FBTYPE (a parameter of FREEBUSY, which is a property > of a VFREEBUSY component). From "4.2.9 Free/Busy Time Type" (fbtype): > > Description: The parameter specifies the free or busy time type. The > value FREE indicates that the time interval is free for scheduling. > The value BUSY indicates that the time interval is busy because one > or more events have been scheduled for that interval. The value > BUSY-UNAVAILABLE indicates that the time interval is busy and that > the interval can not be scheduled. The value BUSY-TENTATIVE indicates > that the time interval is busy because one or more events have been > tentatively scheduled for that interval. If not specified on a > property that allows this parameter, the default is BUSY. > > The above clearly states that there are four (4) levels of free/busy: > > FREE > BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE > > What I'm missing is a way to map from an Event's TRANSP property which > has only two states (FREE or BUSY) to these four states. It is not a 1:1 mapping. That is a time can be marked as BUSY in the FREEBUSY reply and not have an entry in the calendar. That is the issue at the heart of the debate about always automatically returning the CALID busy time and not the CU busy time. There is also the STATUS property that may help. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090302060108080708010306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI0MjEwNDQ0WjAjBgkqhkiG9w0BCQQxFgQU5TsHUjUq7P2G6SoLSHlm cOcc55wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEARNIf+JHSH/fhqlajlXn19TY+rYJr3b2CJ7H5rER+cR7VRlKPo47S41WQyi9lb+W/ oLOSqHcJAsrw1/kVZ+3Q8XyQisi9V4bR3eMgIqvTg18Ek3Bzi0rM5FBoZCIZRuUebUVB+kr/ CosYV5A5Nlf6Wy5tY6qInqaMaEk5y1AtwWo6S8yHqjusreybGaVAtTP/WWNMYMx5cZp/7Bj6 +4jN6whkAyD6zgeSz+S2Phjex3PrTFLEm9IHikrBv9sNbr0j+T6BpzxQz2jU+7392fhjhXIJ Me/ldpjipAjp36HWEBOn68Ugs8Ttgmhcdw7HJdTc3xXsMMBPm9DX66EXUzOnkgAAAAAAAA== --------------ms090302060108080708010306-- From owner-ietf-calendar@mail.imc.org Mon Nov 24 19:30:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13435 for ; Mon, 24 Nov 2003 19:30:24 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP03TkT075028 for ; Mon, 24 Nov 2003 16:03:29 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP03TmE075027 for ietf-calendar-bks; Mon, 24 Nov 2003 16:03:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP03RkT075022 for ; Mon, 24 Nov 2003 16:03:27 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:FjdbVXYqkA57ANYKUgk2cJhlz8dJlTSb@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAP03BaM007682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Nov 2003 16:03:29 -0800 Message-ID: <3FC29C3E.8050805@Royer.com> Date: Mon, 24 Nov 2003 17:03:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: list of items (recur-id is not CAP) References: <0HOV00BAJBJKXY@mpkmail.eng.sun.com> In-Reply-To: <0HOV00BAJBJKXY@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070105080103050801070407" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070105080103050801070407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Arnaud Quillaud wrote: >Actually, if I understand it correctly, the following section of CAP >seems to make use of the "wrong" model for recurrence-id: ><< >6.1.1.15 Query by Date-Time range > > This query selects the entire content of every booked "VEVENT" > component that has an instance greater than or equal to July 1st, > 2000 00:00:00 UTC and less than or equal to July 30st, 2000 23:59:59 > UTC. This includes single instance "VEVENT" components that do no > explicitly contain any recurrence properties or "RECURRENCE-ID" > properties. This works only for CSs that have the "RECUR-EXPAND" > property value set to "TRUE" in the "GET-CAPABILITY" exchange. > > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT > WHERE RECURRENCE-ID >= '20000701T000000Z' > AND RECURRENCE-ID <= '20000730T235959Z' > AND STATE() = 'BOOKED' > END:VQUERY > > >Since the recurrence-id of an instance might not correspond to its >current dtstart, the example above won't do what its description says it >should do. >Why can't we use the DTSTART for this type of query ? > If you sent: QUERY:SELECT * FROM VEVENT WHERE DTSTART >='20000701T000000Z' AND DTSTART <='20000730T235959Z' You would get back VEVENTs with a DTSTART property value between those two dates. If a recurring VEVENT existed and was daily starting from DTSTART:19990101T000000Z, it would not match the query, even when one of its instances (RECURRENCE-ID) did match. The same is true if the VEVENT had a RDATE:20000702T000000Z, as you did not query for RDATE, it would not match as RDATE is not DTSTART. The DTSTART value only matches the RECURRENCE-ID on the first instance of a repeating object. If you query for DTSTART values, that is what you will get. If you query for RECURRENCE-ID values, then you get any VEVENT that has an effective instance start time that matches that value (somehow stored or computed). All objects with an RRULE or RDATE property values have virtual RECURRENCE-ID's even when an RECURRENCE-ID was not explicitly sent or stored in the object. What do you think you would get back if EXPAND:FALSE were in the CAP example? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070105080103050801070407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI1MDAwMzEwWjAjBgkqhkiG9w0BCQQxFgQUnTX/DvtLgLcjW8Nr3w1I 6v4HS/wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAdPMMRHE3gT5umUW5XboGhlawb2kbL78zgvWAcUDzIx/wAA/TiiVlaOBB56xtMlmx 1c8vxqxsLthb8VAA3ZcD6xgdn+KAKT3Z/E/9r6eeXLC+v1NZg31OMS37oqG0keow29fzdZ3k 3T/iixr4hbgda3DaA6cYxW0fBaQP4wqMufduDJ8tS7M/h1uafW0+fsPBeyHyCl3HpcNj5IxD vLE0LpAAe29folqt0AEOl0Uf+9qaizFhXNE4xh7jrgg1ymqGqQzDa/vlVOjmKn6SMrMxfRzI 0aC7pLBwcR082++UmzWPpiJD0VhV/J8geMiwZyLeN8/ydqHR/A+COsiL+CzUegAAAAAAAA== --------------ms070105080103050801070407-- From owner-ietf-calendar@mail.imc.org Mon Nov 24 23:42:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20294 for ; Mon, 24 Nov 2003 23:42:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP4IAib085288 for ; Mon, 24 Nov 2003 20:18:10 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP4IAaC085287 for ietf-calendar-bks; Mon, 24 Nov 2003 20:18:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP4I8ib085276 for ; Mon, 24 Nov 2003 20:18:08 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc13) with SMTP id <200311250418040160049emee> (Authid: TimHare); Tue, 25 Nov 2003 04:18:04 +0000 Message-Id: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 24 Nov 2003 23:10:32 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: Clarification for Free/Busy In-Reply-To: <0HOV00GX6AXI55@ha13sca-mail1.sfbay.sun.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One mapping that makes sense to me in my reading of RFC 2445 (others might disagree) - hope the tabs format this correctly:

                                        |  STATUS of VEVENT                             |
 VEVENT in period       | TENTATIVE             | CONFIRMED             | CANCELLED     | not there
 abd TRANSP             |                       |                       |               |
 ===============        |=================      |=================      |===========    |==========
 No  / (none)                   | FREE                  | FREE                  | FREE          | FREE
 Yes/ OPAQUE    | BUSY-TENTATIVE        | BUSY-UNAVAILABLE      | FREE          | BUSY
 Yes/ TRANSPARENT       | FREE                  | FREE                  | FREE          | FREE

Notice the last line is all "FREE" - this is because TRANSPARENT is explicitly identified as being transparent to free-busy searches.

Tim Hare
Interested Bystander, Non-Inc.


At 09:52 AM 11/24/03 -0800, you wrote:
I am hoping that someone can clarify how to map from a VEVENT component's properties to what should be returned for a Free/Busy request.
 
RFC 2445 states unambiguously that TRANSP is the property that is to be used to return Free/Busy status. From "4.8.2.7 Time Transparency":
 
Description: Time Transparency is the characteristic of an event that
    determines whether it appears to consume time on a calendar. Events
    that consume actual time for the individual or resource associated
    with the calendar SHOULD be recorded as OPAQUE, allowing them to be
    detected by free-busy time searches. Other events, which do not take
    up the individual's (or resource's) time SHOULD be recorded as
    TRANSPARENT, making them invisible to free-busy time searches.
 

This seems clear until I read the description of the free busy time type parameter, FBTYPE (a parameter of FREEBUSY, which is a property of a VFREEBUSY component). From "4.2.9 Free/Busy Time Type" (fbtype):
 
Description: The parameter specifies the free or busy time type. The
    value FREE indicates that the time interval is free for scheduling.
    The value BUSY indicates that the time interval is busy because one
    or more events have been scheduled for that interval. The value
    BUSY-UNAVAILABLE indicates that the time interval is busy and that
    the interval can not be scheduled. The value BUSY-TENTATIVE indicates
    that the time interval is busy because one or more events have been
    tentatively scheduled for that interval. If not specified on a
    property that allows this parameter, the default is BUSY.
 
The above clearly states that there are four (4) levels of free/busy:
 
FREE
BUSY
BUSY-UNAVAILABLE
BUSY-TENTATIVE
 
What I'm missing is a way to map from an Event's TRANSP property which has only two states (FREE or BUSY) to these four states.
 
Is the intention that free/busy should be reported by combining TRANSP with some other property or properties? If I just look at the value "tentative", I see that there are actually two places in an Event where I could potentially derive that value: PARTSTAT and STATUS. I don't see any explicit instruction in RFC 2445 for this.
 
Let me rephrase this a bit in the hope of getting a more exact answer. And instead of looking at a VEVENT and deciding what the FBTYPE should be, can we look at what the desired FBTYPE is and work backwards?
 
What does the VEVENT look like that would generate, for example, the following property in a VFREEBUSY component:
 
FREEBUSY;FBTYPE=BUSY-TENTATIVE:20031201T130000Z/20031201T140000Z
 
or to get even more explicit let's take several cases:
 
1. An attendee has been invited to an event and replied with a tentative acceptance. What does the Attendee's copy of that VEVENT look like in order to return
 FREEBUSY;FBTYPE=BUSY-TENTATIVE: <dates >
 
2. An attendee has been invited to an event and replied with a decline. If the attendee retains that event (maybe he want to be able to change his mind later?), what does his copy of that VEVENT look like? I assume that he should report that timeslot as being "FREE":
 FREEBUSY;FBTYPE=FREE: <dates >
 
3. An attendee has been invited to an event and replied with an acceptance. The organizer has then canceled the event, but the Attendee retains a copy (for whatever reason). What does the Attendee's copy of that VEVENT look like in order to return
 FREEBUSY;FBTYPE=FREE: <dates >
 
4. What does anyone's (organizer or attendee) VEVENT copy look like to generate:
 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE: <dates >
 

In case it's not clear, I'm looking for someone to help me out by telling me that the associated VEVENT would look like:
 
TRANSP: <value >
STATUS: <value >
ATTENDEE: <whatever >
 
or any appropriate fields and values that are involved.
 
 
I'd appreciate any help the list can give.
 
 

 
From owner-ietf-calendar@mail.imc.org Tue Nov 25 02:02:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26221 for ; Tue, 25 Nov 2003 02:02:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP6ggib006925 for ; Mon, 24 Nov 2003 22:42:42 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAP6gg1m006922 for ietf-calendar-bks; Mon, 24 Nov 2003 22:42:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAP6gfib006861 for ; Mon, 24 Nov 2003 22:42:41 -0800 (PST) (envelope-from anil.srivastava@Sun.COM) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAP6geUP011434; Mon, 24 Nov 2003 22:42:40 -0800 (PST) Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id hAP6g3G29175; Mon, 24 Nov 2003 22:42:03 -0800 (PST) Received: from nikita.sbcglobal.net (vpn-129-150-16-140.SFBay.Sun.COM [129.150.16.140]) by we-gotmail.red.iplanet.com (Sun ONE Messaging Server 6.0 (built Sep 24 2003)) with ESMTPA id <0HOW00F1ZAMZ2F00@we-gotmail.red.iplanet.com>; Mon, 24 Nov 2003 22:42:39 -0800 (PST) Date: Mon, 24 Nov 2003 22:42:35 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA Subject: Re: Clarification for Free/Busy In-reply-to: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> To: Tim Hare Cc: ietf-calendar@imc.org Reply-to: anil.srivastava@Sun.COM Message-id: Organization: Sun ONE Software - a division of Sun Microsystems Inc [http://www.sun.com/software] MIME-version: 1.0 X-Mailer: Pine 4.58 - Got Pine? Content-type: TEXT/PLAIN; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Accept-Language: English; en X-Endorsement: This message brought to you by Sun ONE Messaging Server 6.0 References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> X-Message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8BIT Ah.. the tabs did not do the trick :-); Tim. I have recreated the table. Correct me if it does not look like the way you intended it to be. > | STATUS of VEVENT > | >VEVENT in period | TENTATIVE | CONFIRMED | CANCELLED | not there >and TRANSP | | | | >=================|===================================================== >No / (none) | FREE | FREE | FREE | FREE >Yes/ OPAQUE | BUSY-TENTATIVE | BUSY-UNAVAILABLE | FREE | BUSY >Yes/ TRANSPARENT | FREE | FREE | FREE | FREE > >Notice the last line is all "FREE" - this is because TRANSPARENT is >explicitly identified as being transparent to free-busy searches. A clarification: by the last 'not there' column you mean an event where the attendee has 'declined' the invitation, ie. their PARTSTAT in that event says 'DECLINED' Anil On 2003-11-24/23:10 [-0500], TimHare@comcast.net [Tim Hare] wrote: > One mapping that makes sense to me in my reading of RFC 2445 (others might disagree) - > hope the tabs format this correctly: > >                                         |  STATUS of > VEVENT                             | >  VEVENT in period       | TENTATIVE             | CONFIRMED             | > CANCELLED     | not there >  abd > TRANSP             |                       |                       |               | >  ===============        |=================      |=================      |===========    |===== > ===== >  No  / (none)                   | FREE                  | FREE                  | > FREE          | FREE >  Yes/ OPAQUE    | BUSY-TENTATIVE        | BUSY-UNAVAILABLE      | FREE          | BUSY >  Yes/ TRANSPARENT       | FREE                  | FREE                  | > FREE          | FREE > > Notice the last line is all "FREE" - this is because TRANSPARENT is explicitly > identified as being transparent to free-busy searches. > > Tim Hare > Interested Bystander, Non-Inc. > > > At 09:52 AM 11/24/03 -0800, you wrote: > I am hoping that someone can clarify how to map from a VEVENT component's > properties to what should be returned for a Free/Busy request. >   > RFC 2445 states unambiguously that TRANSP is the property that is to be > used to return Free/Busy status. From "4.8.2.7 Time Transparency": >   > Description: Time Transparency is the characteristic of an event that >     determines whether it appears to consume time on a calendar. Events >     that consume actual time for the individual or resource associated >     with the calendar SHOULD be recorded as OPAQUE, allowing them to be >     detected by free-busy time searches. Other events, which do not take >     up the individual's (or resource's) time SHOULD be recorded as >     TRANSPARENT, making them invisible to free-busy time searches. >   > > This seems clear until I read the description of the free busy time type > parameter, FBTYPE (a parameter of FREEBUSY, which is a property of a > VFREEBUSY component). From "4.2.9 Free/Busy Time Type" (fbtype): >   > Description: The parameter specifies the free or busy time type. The >     value FREE indicates that the time interval is free for scheduling. >     The value BUSY indicates that the time interval is busy because one >     or more events have been scheduled for that interval. The value >     BUSY-UNAVAILABLE indicates that the time interval is busy and that >     the interval can not be scheduled. The value BUSY-TENTATIVE indicates >     that the time interval is busy because one or more events have been >     tentatively scheduled for that interval. If not specified on a >     property that allows this parameter, the default is BUSY. >   > The above clearly states that there are four (4) levels of free/busy: >   > FREE > BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE >   > What I'm missing is a way to map from an Event's TRANSP property which has > only two states (FREE or BUSY) to these four states. >   > Is the intention that free/busy should be reported by combining TRANSP with > some other property or properties? If I just look at the value "tentative", > I see that there are actually two places in an Event where I could > potentially derive that value: PARTSTAT and STATUS. I don't see any > explicit instruction in RFC 2445 for this. >   > Let me rephrase this a bit in the hope of getting a more exact answer. And > instead of looking at a VEVENT and deciding what the FBTYPE should be, can > we look at what the desired FBTYPE is and work backwards? >   > What does the VEVENT look like that would generate, for example, the > following property in a VFREEBUSY component: >   > FREEBUSY;FBTYPE=BUSY-TENTATIVE:20031201T130000Z/20031201T140000Z >   > or to get even more explicit let's take several cases: >   > 1. An attendee has been invited to an event and replied with a tentative > acceptance. What does the Attendee's copy of that VEVENT look like in order > to return >  FREEBUSY;FBTYPE=BUSY-TENTATIVE: >   > 2. An attendee has been invited to an event and replied with a decline. If > the attendee retains that event (maybe he want to be able to change his > mind later?), what does his copy of that VEVENT look like? I assume that he > should report that timeslot as being "FREE": >  FREEBUSY;FBTYPE=FREE: >   > 3. An attendee has been invited to an event and replied with an acceptance. > The organizer has then canceled the event, but the Attendee retains a copy > (for whatever reason). What does the Attendee's copy of that VEVENT look > like in order to return >  FREEBUSY;FBTYPE=FREE: >   > 4. What does anyone's (organizer or attendee) VEVENT copy look like to > generate: >  FREEBUSY;FBTYPE=BUSY-UNAVAILABLE: >   > > In case it's not clear, I'm looking for someone to help me out by telling > me that the associated VEVENT would look like: >   > TRANSP: > STATUS: > ATTENDEE: >   > or any appropriate fields and values that are involved. >   >   > I'd appreciate any help the list can give. >   >   > >   > > > -- __________ Anil SRIVASTAVA anil.srivastava@Sun.COM From owner-ietf-calendar@mail.imc.org Tue Nov 25 09:23:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18493 for ; Tue, 25 Nov 2003 09:23:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPE1vib081862 for ; Tue, 25 Nov 2003 06:01:57 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPE1vLm081861 for ietf-calendar-bks; Tue, 25 Nov 2003 06:01:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from localhost.lisanza.net (harrie.inet.it [213.92.1.193]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPE1qib081851 for ; Tue, 25 Nov 2003 06:01:53 -0800 (PST) (envelope-from harrie@inet.it) Received: from inet.it (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id hAPE3bw5000581; Tue, 25 Nov 2003 15:03:37 +0100 (CET) Date: Tue, 25 Nov 2003 15:03:36 +0100 Subject: Re: an idea as an alternative to stored queries Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Harrie Hazewinkel , ietf-calendar@imc.org To: Tim Hare From: Harrie Hazewinkel In-Reply-To: <5.2.1.1.0.20031120220448.00a427b0@mail.comcast.net> Message-Id: <297D2322-1F50-11D8-A5A0-0003934A5A7E@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, November 21, 2003, at 04:22 AM, Tim Hare wrote: > > This may have been thought of before, but what if we defined a _small_ > set of commands for the most frequently used queries, documented how > they would work in the protocol, and required them to be supported? > > My proposals: > > GET-TODAY: returns all VEVENTS, VTODOS, VJOURNAL entries for the > current date, expands anything which recurs within the current day; > i.e. a "snapshot" of the current days VCALENDAR entries. > > GET-NEXT: returns next VEVENT whose beginning is after the current > date/time (or, alternatively, a date/time can be passed and the next > VEVENT after that will be returned). If a current date/time is within > a VEVENT's DTSTART/DTEND range, how would we return that. Two things came to mind here. 1) The above 2 commands look like 'SNMP'. 2) I do not see a real advantage for both client and server. A) For a client you have to specify the current date and timezone. The timezone is needed to tell the server what dat he means in particular and must adjust it to the clients timezone. The server maybe in a different timezone. B) The server must translate this somehow into a query for a specific start and stop time. As a result, I believe the request is little easier on the client, but now more burden on a server. Or am I missing something?? > > PUT-VJOURNAL: create a VJOURNAL event for the current date/time with > the text passed. Can you elaborate?? Since I believe this is close to a CREATE and then there is no benefit. > > There may of course be others, these three are those I would use > myself off the top of my head. In general, I think it could be interesting to look at which common request are mainly made, but I believe more strongly that having 'generic' commands can serve a better purpose. > I believe this solves the problem for small-footprint CUAs, with > little memory, (if such devices still exist by the time we get CAP out > ) better than the stored queries method. The CUA only needs to > send the command - the variables, which in most cases are date or > date/time values, are implicitly defined from the clock of the > responding CUA/CS. This also eliminates the issues of network traffic > since the CUA doesn't have to send a command to find the query, > retrieve that query, modify it, and then send it as a series of > commands. The CUA just has to send one of the commands, and the > desired results are returned. I would earlier believe that a mechanism to limit the amount of components returned on a request woul help. > If this proposal is accepted, my belief is that we should concurrently > drop the idea of stored queries as it now exists. Why?? Just curious, not selecting a side. regards, Harrie From owner-ietf-calendar@mail.imc.org Tue Nov 25 09:34:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18968 for ; Tue, 25 Nov 2003 09:34:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPEGtib082586 for ; Tue, 25 Nov 2003 06:16:55 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPEGt61082585 for ietf-calendar-bks; Tue, 25 Nov 2003 06:16:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centive.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAPEGrib082568 for ; Tue, 25 Nov 2003 06:16:54 -0800 (PST) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003112509321727125 for ; Tue, 25 Nov 2003 09:32:17 -0500 Received: from centive.com ([10.10.48.119]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 09:13:53 -0500 Message-ID: <3FC363A1.7050903@centive.com> Date: Tue, 25 Nov 2003 09:13:53 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: an idea as an alternative to stored queries References: <297D2322-1F50-11D8-A5A0-0003934A5A7E@inet.it> In-Reply-To: <297D2322-1F50-11D8-A5A0-0003934A5A7E@inet.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2003 14:13:53.0905 (UTC) FILETIME=[5B72BE10:01C3B35E] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > B) The server must translate this somehow into a query for a specific > start and stop time. As a result, I believe the request is little > easier on the client, but now more burden on a server. Except that the server can be optimized for the standard queries, instead of having to parse incoming SQL from the client. -- /=====================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=====================================================| |"The Reality Check's in the mail." --L. Peter Deutsch| \=====================================================/ From owner-ietf-calendar@mail.imc.org Tue Nov 25 12:17:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27976 for ; Tue, 25 Nov 2003 12:17:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFvOib088264 for ; Tue, 25 Nov 2003 07:57:24 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPFvNhS088263 for ietf-calendar-bks; Tue, 25 Nov 2003 07:57:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mail.exchange.ximian.com (mr-nutty.ximian.com [141.154.95.31]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPFvMib088255 for ; Tue, 25 Nov 2003 07:57:23 -0800 (PST) (envelope-from danw@ximian.com) Received: from twelve-monkeys by owa.ximian.com; 25 Nov 2003 10:57:17 -0500 Subject: Re: Clarification for Free/Busy From: Dan Winship To: anil.srivastava@Sun.COM Cc: Tim Hare , ietf-calendar@imc.org In-Reply-To: References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 25 Nov 2003 10:57:17 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > | STATUS of VEVENT > > | > >VEVENT in period | TENTATIVE | CONFIRMED | CANCELLED | not there > >and TRANSP | | | | > >=================|===================================================== > >No / (none) | FREE | FREE | FREE | FREE > >Yes/ OPAQUE | BUSY-TENTATIVE | BUSY-UNAVAILABLE | FREE | BUSY > >Yes/ TRANSPARENT | FREE | FREE | FREE | FREE RFC 2445 says "The value BUSY indicates that the time interval is busy because one or more events have been scheduled for that interval. BUSY-UNAVAILABLE indicates that the time interval is busy and that the interval can not be scheduled." So OPAQUE+CONFIRMED is BUSY, not BUSY-UNAVAILABLE, since the interval has been scheduled. BUSY-UNAVAILABLE is like "I'm on vacation during this period" or "This is a holiday" or "These hours are outside my work day". (Assuming a work-related calendar.) -- Dan From owner-ietf-calendar@mail.imc.org Tue Nov 25 14:38:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04439 for ; Tue, 25 Nov 2003 14:38:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPI9wib093146 for ; Tue, 25 Nov 2003 10:09:58 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPI9wZS093145 for ietf-calendar-bks; Tue, 25 Nov 2003 10:09:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPI9wib093139 for ; Tue, 25 Nov 2003 10:09:58 -0800 (PST) (envelope-from anil.srivastava@Sun.COM) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAPI9sUP007662; Tue, 25 Nov 2003 10:09:54 -0800 (PST) Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id hAPI9FB12956; Tue, 25 Nov 2003 10:09:15 -0800 (PST) Received: from nikita.red.iplanet.com (dhcp-usca15-127-38.red.iplanet.com [192.18.127.38]) by we-gotmail.red.iplanet.com (Sun ONE Messaging Server 6.0 (built Sep 24 2003)) with ESMTPA id <0HOX00F486GE2F00@we-gotmail.red.iplanet.com>; Tue, 25 Nov 2003 10:09:53 -0800 (PST) Date: Tue, 25 Nov 2003 10:09:50 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA Subject: Re: Clarification for Free/Busy In-reply-to: <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> To: Dan Winship Cc: Tim Hare , ietf-calendar@imc.org Reply-to: anil.srivastava@Sun.COM Message-id: Organization: Sun ONE Software - a division of Sun Microsystems Inc [http://www.sun.com/software] MIME-version: 1.0 X-Mailer: Pine 4.58 - Got Pine? Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Endorsement: This message brought to you by Sun ONE Messaging Server 6.0 References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> X-Message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT That makes sense. Still no feedback on if an attendee has declined an invitation. I am assuming that would mean FREE, regardless of the value of TRANSP. On 2003-11-25/10:57 [-0500], danw@ximian.com [Dan Winship] wrote: > > > > | STATUS of VEVENT > > > | > > >VEVENT in period | TENTATIVE | CONFIRMED | CANCELLED | not there > > >and TRANSP | | | | > > >=================|===================================================== > > >No / (none) | FREE | FREE | FREE | FREE > > >Yes/ OPAQUE | BUSY-TENTATIVE | BUSY-UNAVAILABLE | FREE | BUSY > > >Yes/ TRANSPARENT | FREE | FREE | FREE | FREE > > RFC 2445 says "The value BUSY indicates that the time interval is busy > because one or more events have been scheduled for that interval. > BUSY-UNAVAILABLE indicates that the time interval is busy and that the > interval can not be scheduled." So OPAQUE+CONFIRMED is BUSY, not > BUSY-UNAVAILABLE, since the interval has been scheduled. > > BUSY-UNAVAILABLE is like "I'm on vacation during this period" or "This > is a holiday" or "These hours are outside my work day". (Assuming a > work-related calendar.) > > -- Dan > -- __________ Anil SRIVASTAVA anil.srivastava@Sun.COM From owner-ietf-calendar@mail.imc.org Tue Nov 25 14:44:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04659 for ; Tue, 25 Nov 2003 14:44:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPI9nib093137 for ; Tue, 25 Nov 2003 10:09:49 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPI9n7R093136 for ietf-calendar-bks; Tue, 25 Nov 2003 10:09:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPI9nib093131 for ; Tue, 25 Nov 2003 10:09:49 -0800 (PST) (envelope-from arnaud.quillaud@sun.com) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAPI9jUP007588 for ; Tue, 25 Nov 2003 10:09:45 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM [129.146.18.131]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAPI9UDS023052; Tue, 25 Nov 2003 10:09:31 -0800 (PST) Received: from iabs-2k.red.iplanet.com (iabs-2k.red.iplanet.com [192.18.144.144]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.2 Patch 1 (built Apr 2 2002)) with ESMTP id <0HOX008Z86G9VM@mpkmail.eng.sun.com>; Tue, 25 Nov 2003 10:09:45 -0800 (PST) Date: Tue, 25 Nov 2003 10:09:51 -0800 From: Arnaud Quillaud Subject: RE: list of items (recur-id is not CAP) In-reply-to: <3FC29C3E.8050805@Royer.com> To: ietf-calendar@imc.org Message-id: <0HOX008Z96G9VM@mpkmail.eng.sun.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Doug Royer [mailto:Doug@Royer.com] > Sent: Monday, November 24, 2003 4:03 PM > To: ietf-calendar@imc.org > Subject: Re: list of items (recur-id is not CAP) > > > > > Arnaud Quillaud wrote: > > >Actually, if I understand it correctly, the following section of CAP > >seems to make use of the "wrong" model for recurrence-id: > ><< > >6.1.1.15 Query by Date-Time range > > > > This query selects the entire content of every booked "VEVENT" > > component that has an instance greater than or equal to July 1st, > > 2000 00:00:00 UTC and less than or equal to July 30st, > 2000 23:59:59 > > UTC. This includes single instance "VEVENT" components that do no > > explicitly contain any recurrence properties or "RECURRENCE-ID" > > properties. This works only for CSs that have the "RECUR-EXPAND" > > property value set to "TRUE" in the "GET-CAPABILITY" exchange. > > > > BEGIN:VQUERY > > EXPAND:TRUE > > QUERY:SELECT * FROM VEVENT > > WHERE RECURRENCE-ID >= '20000701T000000Z' > > AND RECURRENCE-ID <= '20000730T235959Z' > > AND STATE() = 'BOOKED' > > END:VQUERY > > > > > >Since the recurrence-id of an instance might not correspond to its > >current dtstart, the example above won't do what its > description says it > >should do. > >Why can't we use the DTSTART for this type of query ? > > > If you sent: > > QUERY:SELECT * FROM VEVENT > WHERE DTSTART >='20000701T000000Z' > AND DTSTART <='20000730T235959Z' > > You would get back VEVENTs with a DTSTART property value between > those two dates. If a recurring VEVENT existed and was daily starting > from DTSTART:19990101T000000Z, it would not match the query, even > when one of its instances (RECURRENCE-ID) did match. The same is Why ? Each of the instances of a recurring event has a DTSTART as far as I know. Why would we take into account only the first instance ? > true if the VEVENT had a RDATE:20000702T000000Z, as you did not > query for RDATE, it would not match as RDATE is not DTSTART. > > The DTSTART value only matches the RECURRENCE-ID on the first instance > of a repeating object. If you query for DTSTART values, that > is what you > will get. > If you query for RECURRENCE-ID values, then you get any VEVENT that > has an effective instance start time that matches that value > (somehow stored > or computed). That is true only if the RECURRENCE-ID of the instance matches the DTSTART of this instance. If this instance was originally: RECURRENCE-ID:20000729T000000Z DTSTART:20000729T000000Z but the DTSTART is moved to 20000802T000000Z we end up with RECURRENCE-ID:20000729T000000Z DTSTART:20000802T000000Z If the "Query by Date-Time range" in the CAP example is done using the RECURRENCE-ID, this particular instance will be returned when it actually doesn't belong to that range. > > All objects with an RRULE or RDATE property values have virtual > RECURRENCE-ID's even when an RECURRENCE-ID was > not explicitly sent or stored in the object. > > What do you think you would get back if EXPAND:FALSE were in > the CAP example? My understanding is that we would return any event object that has at least one instance that matches the filter (whether it is RECURRENCE-ID or DTSTART). So for recurring event, we would return the MASTER event (the one containing RRULE/RDATE) and all its exceptions if there are any. If we take a daily VEVENT starting from DTSTART:19990101T000000Z and recurring forever, it would be a match even though the DTSTART of this master event is not in the range. So we would get back: BEGIN:VEVENT DTSTART:19990101T000000Z RRULE:FREQ=DAILY ... But that is far from being obvious. After reading the CAP spec, I should say that I don't know. Arnaud From owner-ietf-calendar@mail.imc.org Tue Nov 25 14:56:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05244 for ; Tue, 25 Nov 2003 14:56:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPIJAib093630 for ; Tue, 25 Nov 2003 10:19:10 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPIJAgB093629 for ietf-calendar-bks; Tue, 25 Nov 2003 10:19:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPIJ9ib093618 for ; Tue, 25 Nov 2003 10:19:09 -0800 (PST) (envelope-from satyanarayana.vempati@Sun.COM) Received: from phys-ha13sca-1 ([129.145.155.91]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAPIJ5UP013164 for ; Tue, 25 Nov 2003 10:19:05 -0800 (PST) Received: from pranav (pranav.red.iplanet.com [192.18.144.109]) by ha13sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.03 (built Oct 1 2002)) with ESMTP id <0HOX00CTW6VT0Q@ha13sca-mail1.sfbay.sun.com> for ietf-calendar@imc.org; Tue, 25 Nov 2003 10:19:05 -0800 (PST) Date: Tue, 25 Nov 2003 10:19:14 -0800 From: Satyanarayana Vempati Subject: RE: Clarification for Free/Busy In-reply-to: <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> To: ietf-calendar@imc.org Message-id: <000501c3b380$a219a000$6d9012c0@red.iplanet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In a group scheduled calendar component, the STATUS property is used by the "Organizer" to provide a confirmation of the event to the "Attendees". Shouldn't PARTSTAT also be taken into account for an attendee's calendar? -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Dan Winship Sent: Tuesday, November 25, 2003 7:57 AM To: anil.srivastava@Sun.COM Cc: Tim Hare; ietf-calendar@imc.org Subject: Re: Clarification for Free/Busy > > | STATUS of VEVENT > > | > >VEVENT in period | TENTATIVE | CONFIRMED | CANCELLED | not there > >and TRANSP | | | | > >=================|===================================================== > >No / (none) | FREE | FREE | FREE | FREE > >Yes/ OPAQUE | BUSY-TENTATIVE | BUSY-UNAVAILABLE | FREE | BUSY > >Yes/ TRANSPARENT | FREE | FREE | FREE | FREE RFC 2445 says "The value BUSY indicates that the time interval is busy because one or more events have been scheduled for that interval. BUSY-UNAVAILABLE indicates that the time interval is busy and that the interval can not be scheduled." So OPAQUE+CONFIRMED is BUSY, not BUSY-UNAVAILABLE, since the interval has been scheduled. BUSY-UNAVAILABLE is like "I'm on vacation during this period" or "This is a holiday" or "These hours are outside my work day". (Assuming a work-related calendar.) -- Dan From owner-ietf-calendar@mail.imc.org Tue Nov 25 15:30:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08153 for ; Tue, 25 Nov 2003 15:30:15 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJA9ib096235 for ; Tue, 25 Nov 2003 11:10:09 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPJA9Ma096234 for ietf-calendar-bks; Tue, 25 Nov 2003 11:10:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJA8ib096229 for ; Tue, 25 Nov 2003 11:10:08 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:QUxZbqofTRERGxjVhIarpRbFQfQUCfvD@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAPJA6aM019171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Nov 2003 11:10:09 -0800 Message-ID: <3FC3A90D.8060009@Royer.com> Date: Tue, 25 Nov 2003 12:10:05 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Clarification for Free/Busy References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> In-Reply-To: <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010103010502050203070506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010103010502050203070506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Don't forget the two new CAP TRANSP values: / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects ; can overlap it. / "OPAQUE-NOCONFLICT" ; Opaque on busy time ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects ; can overlap it. Dan Winship wrote: >>> | STATUS of VEVENT >>> | >>>VEVENT in period | TENTATIVE | CONFIRMED | CANCELED | not there >>>and TRANSP | | | | >>>=================|===================================================== >>>No / (none) | FREE | FREE | FREE | FREE >>>Yes/ OPAQUE | BUSY-TENTATIVE | BUSY-UNAVAILABLE | FREE | BUSY >>>Yes/ TRANSPARENT | FREE | FREE | FREE | FREE >>> >>> > >RFC 2445 says "The value BUSY indicates that the time interval is busy >because one or more events have been scheduled for that interval. >BUSY-UNAVAILABLE indicates that the time interval is busy and that the >interval can not be scheduled." So OPAQUE+CONFIRMED is BUSY, not >BUSY-UNAVAILABLE, since the interval has been scheduled. > >BUSY-UNAVAILABLE is like "I'm on vacation during this period" or "This >is a holiday" or "These hours are outside my work day". (Assuming a >work-related calendar.) > >-- Dan > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010103010502050203070506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI1MTkxMDA1WjAjBgkqhkiG9w0BCQQxFgQUn67tpvmNNTFKVlZ+6dYE LCVWyBcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAyTZwrqDHOGoPR4FODnukwcXz5PZH9JwlYlAL+P8m427VvJCcqj64Z0FZpPN1sJu+ yb6NReB0k24NyuWmuuuB4Kqi/0ttE4HWgMqh8OREFTayhQa6sV1xATPpl6if9dgJaEXu+lfI 4O2Z2+bWDmjP3UbAcsZWPYDNOhmnHu8ZvXXjFr+mfdSyBGPIDVLEV3ktS8iCs5fvOsWyYGIU Gd01ZtpUXJT+SuYSJNHsBEfZRRJUdTdrTkqeA585IAaRSKv6Exm+ny0S6MF6bb1awcQ0pHis ly14m+mYNDwCdju+hvuGi507VSRvx2yNSCZgrpz2Le0LFGelyDdB8qeHIFNL1AAAAAAAAA== --------------ms010103010502050203070506-- From owner-ietf-calendar@mail.imc.org Tue Nov 25 16:17:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11098 for ; Tue, 25 Nov 2003 16:17:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJtrib097975 for ; Tue, 25 Nov 2003 11:55:53 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPJtrFQ097974 for ietf-calendar-bks; Tue, 25 Nov 2003 11:55:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJtpib097968 for ; Tue, 25 Nov 2003 11:55:52 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Hc/bW1x43Yvro0qYiAXg3GHs65s0DUnd@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAPJtoaM019610 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Nov 2003 11:55:52 -0800 Message-ID: <3FC3B3C5.6020803@Royer.com> Date: Tue, 25 Nov 2003 12:55:49 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Clarification for Free/Busy (CAP-auto-generate only?) References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000508070905010203070007" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000508070905010203070007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit These discussions seem to presume the process can always be automated. A CU could wish for the time to be BUSY in case they change their mind later. In which case the CU would want the time to be BUSY even if declined. The publishing of static VFREEBUSY information is a valid RFC-2446 thing to do, and it can be independent of the CAP/BOOKED auto generated VFREEBUSY discussion. So unless we are deprecating RFC-2446 VFREEBUSY/PUBLISH (and please no), then I assume these discussions are assuming CAP auto generated VFREEBUSY BOOKED replies? Anil SRIVASTAVA wrote: >That makes sense. Still no feedback on if an attendee has declined an >invitation. I am assuming that would mean FREE, regardless of the value >of TRANSP. > >On 2003-11-25/10:57 [-0500], danw@ximian.com [Dan Winship] wrote: > > > >> >> > > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000508070905010203070007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI1MTk1NTQ5WjAjBgkqhkiG9w0BCQQxFgQU/6xb98VreCpcUAXx9xyH Qubyht4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAoUTonn2I1WSm4R+pZvKiaBPzoUUcrh1QFDgggalqspkI1Yf0gCwgjhVGQ2krAlwq ud6TWiT7TIyI4w0RYPDSpkYSpR4HfHzhwmQOTUgDuLrWHnfI5hKY/I5qs+L/nNAakxXMgLZs Acz1K8qi4CLJ2X9ca1XndvE2V+68KC4fKRqxfUh1Ulpj3lZUSUfwZ6C5mDLOJTkJt9J97MR8 LDjDzPLmnpeVMd6UaxXmJfz4fIkdHuSj/HPvpkl/iG4cS/ZK+vK+kxEvjfhtvkvgQINSj6bz YcAmaYwFBUKyVUf/UfgwImzVQ/2Rmt1UVoKWGaIx0tIhyFa9WxfWzQAEUewauAAAAAAAAA== --------------ms000508070905010203070007-- From owner-ietf-calendar@mail.imc.org Tue Nov 25 16:44:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12449 for ; Tue, 25 Nov 2003 16:44:09 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPKRXib099259 for ; Tue, 25 Nov 2003 12:27:33 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPKRXuO099258 for ietf-calendar-bks; Tue, 25 Nov 2003 12:27:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPKRVib099253 for ; Tue, 25 Nov 2003 12:27:31 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:/PJcXmXbi6QjoAe3vPSsunPmi72oB1TG@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAPKRUaM019993 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Nov 2003 12:27:32 -0800 Message-ID: <3FC3BB32.2030104@Royer.com> Date: Tue, 25 Nov 2003 13:27:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: list of items (recur-id is not CAP) References: <0HOX008Z96G9VM@mpkmail.eng.sun.com> In-Reply-To: <0HOX008Z96G9VM@mpkmail.eng.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040302050705070908070101" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040302050705070908070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Arnaud Quillaud wrote: >>If you sent: >> >> QUERY:SELECT * FROM VEVENT >> WHERE DTSTART >='20000701T000000Z' >> AND DTSTART <='20000730T235959Z' >> >>You would get back VEVENTs with a DTSTART property value between >>those two dates. If a recurring VEVENT existed and was daily starting >>from DTSTART:19990101T000000Z, it would not match the query, even >>when one of its instances (RECURRENCE-ID) did match. The same is >> >> > >Why ? Each of the instances of a recurring event has a DTSTART as far as I know. >Why would we take into account only the first instance ? > The object that would be returned with a RECURRENCE-ID as shown in the CAP QUERY example would return: VEVENT: DTSTART:19990101T000000Z RECURRENCE-ID: ...something that matched.... So the DTSTART still does not match, however the RECURRENCE-ID that is calculated from EXPAND:TRUE does match. When expanding an existing recurring object, you do not modify the DTSTART value, you add a RECURRENCE-ID property to be the effective start time of the Nth instance(s) that match. >>true if the VEVENT had a RDATE:20000702T000000Z, as you did not >>query for RDATE, it would not match as RDATE is not DTSTART. >> >>The DTSTART value only matches the RECURRENCE-ID on the first instance >>of a repeating object. If you query for DTSTART values, that >>is what you >>will get. >>If you query for RECURRENCE-ID values, then you get any VEVENT that >>has an effective instance start time that matches that value >>(somehow stored >>or computed). >> >> > >That is true only if the RECURRENCE-ID of the instance matches the DTSTART of this instance. > The first instance always matches the DTSTART value, else you could never compute the second. And 2445: The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. >If this instance was originally: > >RECURRENCE-ID:20000729T000000Z >DTSTART:20000729T000000Z > > but the DTSTART is moved to 20000802T000000Z > >we end up with > >RECURRENCE-ID:20000729T000000Z >DTSTART:20000802T000000Z > The 1st instance can not be less than the DTSTART value as 2445 mandates that DTSTART is the first instance. >If the "Query by Date-Time range" in the CAP example is done using the RECURRENCE-ID, this particular instance will be returned when it actually doesn't belong to that range. > You example was not valid. >>All objects with an RRULE or RDATE property values have virtual >>RECURRENCE-ID's even when an RECURRENCE-ID was >>not explicitly sent or stored in the object. >> >>What do you think you would get back if EXPAND:FALSE were in >>the CAP example? >> >> > >My understanding is that we would return any event object that has at least one instance that matches the filter (whether it is RECURRENCE-ID or DTSTART). >So for recurring event, we would return the MASTER event (the one containing RRULE/RDATE) and all its exceptions if there are any. > If you have EXPAND:TRUE, and query for RECURRENCE-ID, then ALL matching VEVENTs that contain any RRULE or RDATE would also contain a calculated RECURRENCE-ID. Without the RECURRENCE-ID in a returned object that also contains an RRULE or RDATE, then that object returned is specifying a set of UNexpaned instances. So no, you would not get back the master object that contained unexpanded instances. If you have EXPAND:FALSE and query for RECURRENCE-ID, you will get back one object without any RECURRENCE-ID, which if expanded would match. If you have EXPAND:TRUE and query for DTSTART, you will only get objects that have a DTSTART value in that range. If you have EXPAND:FALSE and query for DTSTART, you will only get objects that have a DTSTART value in that range. >If we take a daily VEVENT starting from DTSTART:19990101T000000Z and recurring forever, it would be a match even though the DTSTART of this master event is not in the range. >So we would get back: > >BEGIN:VEVENT >DTSTART:19990101T000000Z >RRULE:FREQ=DAILY >... > > Again, DTSTART is not modified, only RECURRENCE-ID is added to the returned object(s) in EXPAND:TRUE. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040302050705070908070101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI1MjAyNzMwWjAjBgkqhkiG9w0BCQQxFgQUnbbGfxUMjrTZAa1yqdhD fXY4+MMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEATEJae+GmRLxrwM44kE1+zh/cuPzeP0KUZdRh2/qEOlTJ93QCHD3nOK9VY80SoFcb HFBxMWN49kwNaaeIIis5cEn0l2PL+gb1IaP8RDoGQxNUMXy52bL5SsVsgdnPPR4jBspAzhV3 Ef7HIjbT+JYhBzUNAHWazJdo18gSt74knJtde3LroBvIwUR2/3M33prixv7z+mgFz5zwwa6R ylmn2xfvse60RtU94ahkVKBXsnGaaQ4rc3dEjqhyh8tgY/nfv1ZAITMLyygbaZn2J/xTfe2r FR55Y/u24FwqDqgQiNIe9mIYDjZRBg+ri7op+w3KVPcPYlxC79ixG1yxzPtAGgAAAAAAAA== --------------ms040302050705070908070101-- From owner-ietf-calendar@mail.imc.org Tue Nov 25 18:36:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18112 for ; Tue, 25 Nov 2003 18:36:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPMFuib003403 for ; Tue, 25 Nov 2003 14:15:56 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAPMFtOQ003402 for ietf-calendar-bks; Tue, 25 Nov 2003 14:15:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPMFtib003395 for ; Tue, 25 Nov 2003 14:15:55 -0800 (PST) (envelope-from anil.srivastava@Sun.COM) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAPMFqxA015738; Tue, 25 Nov 2003 14:15:52 -0800 (PST) Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id hAPMFFG24126; Tue, 25 Nov 2003 14:15:15 -0800 (PST) Received: from nikita.red.iplanet.com (dhcp-usca15-127-38.red.iplanet.com [192.18.127.38]) by we-gotmail.red.iplanet.com (Sun ONE Messaging Server 6.0 (built Sep 24 2003)) with ESMTPA id <0HOX00F57HUD2F00@we-gotmail.red.iplanet.com>; Tue, 25 Nov 2003 14:15:52 -0800 (PST) Date: Tue, 25 Nov 2003 14:15:48 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA Subject: Re: Clarification for Free/Busy (CAP-auto-generate only?) In-reply-to: <3FC3B3C5.6020803@Royer.com> To: "ietf-calendar@imc.org" Reply-to: anil.srivastava@Sun.COM Message-id: Organization: Sun ONE Software - a division of Sun Microsystems Inc [http://www.sun.com/software] MIME-version: 1.0 X-Mailer: Pine 4.58 - Got Pine? Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Endorsement: This message brought to you by Sun ONE Messaging Server 6.0 References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> <1069775837.23749.65.camel@twelve-monkeys.boston.ximian.com> <3FC3B3C5.6020803@Royer.com> X-Message-flag: Outlook: the best virus distribution system around Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT On 2003-11-25/12:55 [-0700], Doug@Royer.com [Doug Royer] wrote: > > These discussions seem to presume the process can always be automated. > A CU could wish for the time to be BUSY in case they change their mind > later. In which case the CU would want the time to be BUSY even if > declined. > > The publishing of static VFREEBUSY information is a valid RFC-2446 > thing to do, and it can be independent of the CAP/BOOKED auto > generated VFREEBUSY discussion. > > So unless we are deprecating RFC-2446 VFREEBUSY/PUBLISH (and please > no), then I assume these discussions are assuming CAP auto generated > VFREEBUSY BOOKED replies? > > Yes. > Anil SRIVASTAVA wrote: > > >That makes sense. Still no feedback on if an attendee has declined an > >invitation. I am assuming that would mean FREE, regardless of the value > >of TRANSP. > > > >On 2003-11-25/10:57 [-0500], danw@ximian.com [Dan Winship] wrote: > > > > > > > >> > >> > > > > > > > > -- __________ Anil SRIVASTAVA anil.srivastava@Sun.COM From owner-ietf-calendar@mail.imc.org Wed Nov 26 07:47:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04856 for ; Wed, 26 Nov 2003 07:47:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQCSjib017015 for ; Wed, 26 Nov 2003 04:28:45 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQCSj1a017014 for ietf-calendar-bks; Wed, 26 Nov 2003 04:28:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.pspl.co.in (www.pspl.co.in [202.54.11.65] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQCSgib017002 for ; Wed, 26 Nov 2003 04:28:43 -0800 (PST) (envelope-from shriram_vishwanathan@persistent.co.in) Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id hAQCSl4p016377 for ; Wed, 26 Nov 2003 17:58:47 +0530 Received: from ps1033 (PS1033.intranet.pspl.co.in [192.168.1.42]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id hAQCSkLp016363 for ; Wed, 26 Nov 2003 17:58:47 +0530 Message-ID: <002f01c3b418$d0401020$2a01a8c0@persistent.co.in> From: "Shriram V" To: Subject: RFC2445/RFC2446: SEQUENCE property Date: Wed, 26 Nov 2003 17:58:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.0 required=6.0 tests=none version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I have a doubt related to SEQUENCE property. Can recurrence instances of a vevent component have a larger(or different) SEQUENCE when the main vevent component (that describes the recurrence set) has a smaller SEQUENCE? or Is SEQUENCE property for a vevent component different than the SEQUENCE property of an individual vevent recurrence instance? If they are different, how are they related? For example an instance update might change only the SEQUENCE of the instance, whereas the main vevent does not change. Please comment. Regards, Shriram V. From owner-ietf-calendar@mail.imc.org Wed Nov 26 12:28:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18286 for ; Wed, 26 Nov 2003 12:28:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQH76ib032374 for ; Wed, 26 Nov 2003 09:07:06 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAQH76Ls032373 for ietf-calendar-bks; Wed, 26 Nov 2003 09:07:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAQH75ib032361 for ; Wed, 26 Nov 2003 09:07:05 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:mkvMFYQWSpnbt1uX2CNZZ83agB8L1voR@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hAQH6xaM008302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Nov 2003 09:07:03 -0800 Message-ID: <3FC4DDB3.7010809@Royer.com> Date: Wed, 26 Nov 2003 10:06:59 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC2445/RFC2446: SEQUENCE property References: <002f01c3b418$d0401020$2a01a8c0@persistent.co.in> In-Reply-To: <002f01c3b418$d0401020$2a01a8c0@persistent.co.in> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080404070004040602030300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080404070004040602030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Shriram V wrote: >Hi all, > >I have a doubt related to SEQUENCE property. > >Can recurrence instances of a vevent component have a >larger(or different) SEQUENCE when the main vevent >component (that describes the recurrence set) has a >smaller SEQUENCE? > If you have: VEVENT: UID:1, SEQUENCE:6 (NO RECURRENCE-ID) Then you get a: VEVENT: UID:1, SEQUENCE:7 (With a RECURENCE-ID) then you are being told that the new SEQUENCE number is 7 and that exactly one instance has been updated with the details in the new object. Now the main vevent is also at 7. If you have: VEVENT: UID:1, SEQUENCE:6 (NO RECURRENCE-ID) Then you get a: VEVENT: UID:1, SEQUENCE:5 (With a RECURENCE-ID) It is an old object, toss it. >or >Is SEQUENCE property for a vevent component >different than the SEQUENCE property of an individual >vevent recurrence instance? If they are different, how are >they related? > >For example an instance update might change only the >SEQUENCE of the instance, whereas the main vevent >does not change. > See section 4.4.2 of iTIP. You update the main vevent, increment its sequence. Then if there is just one instance update, you can choose to send out an update that specifies just that change. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080404070004040602030300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI2MTcwNjU5WjAjBgkqhkiG9w0BCQQxFgQU27owy9JUCr11eNM8Yux+ jmt9qlAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAPPhcQ94ixQ4oQNCb8L7hBqCz9tuEezMqXzq45EjLzwpMnBdgyky9TSkgqHaBqU+F lSIZrrlswaV40zRXIqvJJzwgy4k6AgIHimE/UtY91l4sh1lG5AfBW0mpfTxy3UiOzop1coAQ UDs1ypHSs63Hvs4dxUl7p88UupVFHAXba9g+gjisWxsFkvDGYXfOrojgeV8boRIe4zDrEZl1 O2bG9D5QYA0G09G+WSmJGEkuaVrWr5RQRoF1CwRaXvRrwg+HiBvCJcq8LUgZtmjZ/Ky2rsBz HVW0+M4xkG/mmSXDtz/iw1DaN4kCGKmAoHnkLM+/PoKV0fkG05Z3oWLG7DbceQAAAAAAAA== --------------ms080404070004040602030300-- From owner-ietf-calendar@mail.imc.org Wed Nov 26 23:32:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11517 for ; Wed, 26 Nov 2003 23:32:53 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4Fwib060209 for ; Wed, 26 Nov 2003 20:15:58 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR4Fvfo060208 for ietf-calendar-bks; Wed, 26 Nov 2003 20:15:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4Ftib060201 for ; Wed, 26 Nov 2003 20:15:56 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc13) with SMTP id <2003112704155301600repuce> (Authid: TimHare); Thu, 27 Nov 2003 04:15:53 +0000 Message-Id: <5.2.1.1.0.20031126224015.00a40a60@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 26 Nov 2003 23:08:37 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: Clarification for Free/Busy In-Reply-To: References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: First- let me apologize for the poor formatting of my table - I'll have to come up with a better way to reference information best suited to a table. Second - to clarify one thing, the "not there" column means that the STATUS property of the VEVENT is not present, I was trying to provide for the case where we could not determine the status from the property. Third - since the Free/Busy query is directed toward one explicit calendar UID, I'm not sure we need to worry about attendee PARTSTAT - aren't we really querying the free/busy times on that VCALENDAR/VAGENDA ? Fourth- I'm willing to accept that OPAQUE+CONFIRMED = BUSY instead of BUSY-UNAVAILABLE as Dan Winship stated, but then where do BUSY-UNAVAILABLE statuses come from - other parts of a CUA that "know" my normal working hours? In my use of my calendaring software at work, I have to schedule my vacation time on my calendar. I don't know how I'd indicate that to my software to return that as BUSY-UNAVAILABLE. Not saying it can't be done; I'm just unclear about where it comes from. Fifth- if an attendee has declined an invitation then the time on their calendar should be FREE if (and only if) there is no other VEVENT in that time period. Sixth- this is for automated Free/Busy replies to a query, not to publishing free/busy time since that publishing effort could be done by any number of things. Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Thu Nov 27 00:03:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12549 for ; Thu, 27 Nov 2003 00:03:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4p3ib061534 for ; Wed, 26 Nov 2003 20:51:03 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAR4p35l061533 for ietf-calendar-bks; Wed, 26 Nov 2003 20:51:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAR4p1ib061515 for ; Wed, 26 Nov 2003 20:51:02 -0800 (PST) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (rwcrmhc13) with SMTP id <2003112704505901500pom43e> (Authid: TimHare); Thu, 27 Nov 2003 04:50:59 +0000 Message-Id: <5.2.1.1.0.20031126230935.00a499d0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 26 Nov 2003 23:43:43 -0500 To: ietf-calendar@imc.org From: Tim Hare Subject: Re: an idea as an alternative to stored queries In-Reply-To: <297D2322-1F50-11D8-A5A0-0003934A5A7E@inet.it> References: <5.2.1.1.0.20031120220448.00a427b0@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Not knowing SNMP that well, I'm not going to address your item 1) - I can't tell if it's a good or bad thing to look like SNMP. As to 2) - the advantage to the client is the ability to have simple commands which are understood at the server, instead of building a complicated query or going through a complicated retrieval and modification of a stored query, and in these two cases the client does not need to build DTSTART/DTEND information into a "query" since it's implicit in the definition of the command. The timezone issue does need to be handled, however it's probably pretty easy: In my opinion if the client sends its current timezone along with the date on the GET-TODAY command (or the date/time of the GET-NEXT command), the server should return the responses translated to that timezone if necessary. If the client sends no timezone, the server should send whatever timezone is in the component. Also, if no date or date/time value is sent, the server should use its local clock to supply those values. Also you are correct that my PUT-JOURNAL command is basically the same as CREATE with a VJOURNAL event, so PUT-JOURNAL is not necessary. The reason I suggested dropping stored queries was because we never reached consensus, that I can tell, about how such items would be implemented; my suggestion was to provide some of the function that stored queries were supposed to provide in a simpler manner that would allow the CAP draft to be finished; stored queries can always be designed and included in a future revision to the protocol if people feel the work is worth it. Limiting the amount of components on a request isn't necessarily good, because you might not get the components you want and then you'd have to have a way to generate a query which said "give me everything from *here* onward", send that, see if you got the right stuff, etcetera. This could be a network traffic and response time problem. The two alternatives I propose involve one request and one reply; the scope of the command limits the components _somewhat_ in the GET-TODAY command (how many components could there be for "today" in most use cases?) and to _one_ VEVENT in the GET-NEXT command. This would allow faster response and lower network load. I have, as yet, been unable to think of other commands that would be as useful, or as commonly used. If anyone else has good ones to propose, I do believe that they should be the types of commands that are short and quick like to two above, with minimal client modification required. The most basic use case I can think of is a device with programming in ROM whose function is to download today's information and display it - the entire function, in CAP, would be ROMable using the GET-TODAY command with no timezone and no date passed, yet it could still retrieve the up-to-date information. Tim Hare Interested Bystander, Non-Inc. At 03:03 PM 11/25/03 +0100, you wrote: >On Friday, November 21, 2003, at 04:22 AM, Tim Hare wrote: > >> >>This may have been thought of before, but what if we defined a _small_ >>set of commands for the most frequently used queries, documented how they >>would work in the protocol, and required them to be supported? >> >>My proposals: >> >>GET-TODAY: returns all VEVENTS, VTODOS, VJOURNAL entries for the current >>date, expands anything which recurs within the current day; i.e. a >>"snapshot" of the current days VCALENDAR entries. >> >>GET-NEXT: returns next VEVENT whose beginning is after the current >>date/time (or, alternatively, a date/time can be passed and the next >>VEVENT after that will be returned). If a current date/time is within a >>VEVENT's DTSTART/DTEND range, how would we return that. > >Two things came to mind here. >1) The above 2 commands look like 'SNMP'. > >2) I do not see a real advantage for both client and server. > A) For a client you have to specify the current date and timezone. > The timezone is needed to tell the server what dat he means in > particular > and must adjust it to the clients timezone. The server maybe in a > different > timezone. > B) The server must translate this somehow into a query for a specific > start and stop time. As a result, I believe the request is little > easier on the client, but now more burden on a server. > >Or am I missing something?? > > >> >>PUT-VJOURNAL: create a VJOURNAL event for the current date/time with the >>text passed. > >Can you elaborate?? Since I believe this is close to a CREATE and then >there is no benefit. > >> >>There may of course be others, these three are those I would use myself >>off the top of my head. > >In general, I think it could be interesting to look at which >common request are mainly made, but I believe more strongly that >having 'generic' commands can serve a better purpose. > >>I believe this solves the problem for small-footprint CUAs, with little >>memory, (if such devices still exist by the time we get CAP out ) >>better than the stored queries method. The CUA only needs to send the >>command - the variables, which in most cases are date or date/time >>values, are implicitly defined from the clock of the responding >>CUA/CS. This also eliminates the issues of network traffic since the CUA >>doesn't have to send a command to find the query, retrieve that query, >>modify it, and then send it as a series of commands. The CUA just has to >>send one of the commands, and the desired results are returned. > >I would earlier believe that a mechanism to limit the amount of components >returned on a request woul help. > >>If this proposal is accepted, my belief is that we should concurrently >>drop the idea of stored queries as it now exists. > >Why?? Just curious, not selecting a side. > >regards, > > >Harrie From owner-ietf-calendar@mail.imc.org Thu Nov 27 09:48:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08181 for ; Thu, 27 Nov 2003 09:48:39 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAREW9ib062912 for ; Thu, 27 Nov 2003 06:32:09 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAREW9Z1062911 for ietf-calendar-bks; Thu, 27 Nov 2003 06:32:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.pspl.co.in (www.pspl.co.in [202.54.11.65] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAREW6ib062898 for ; Thu, 27 Nov 2003 06:32:07 -0800 (PST) (envelope-from shriram_vishwanathan@persistent.co.in) Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id hAREWCSO030083 for ; Thu, 27 Nov 2003 20:02:12 +0530 Received: from ps1033 (PS1033.intranet.pspl.co.in [192.168.1.42]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id hAREWALp030063 for ; Thu, 27 Nov 2003 20:02:11 +0530 Message-ID: <009001c3b4f3$37103ed0$2a01a8c0@persistent.co.in> From: "Shriram V" To: "iCAL" Subject: How to handle out-of-sequence ADDs. Date: Thu, 27 Nov 2003 20:01:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01C3B521.4EB4B600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=1.2 required=6.0 tests=HTML_40_50,HTML_MESSAGE version=2.54 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_008D_01C3B521.4EB4B600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I want to know how out of sequence ADD messages is handled. Suppose that a user has an event with SEQ #1 in his store. Now if ADD with SEQ#3 comes up, what should be done? Since the received SEQ# > current SEQ#, this is a more recent ADD.=20 At this point if I accept ADD#3 as update, the SEQ# of the event in my = calendar would increase to #3. Next when older ADD#2 (or any other method) arrives, it will be = rejected, since SEQ# < current SEQ#. In effect, user's version of vevent, although indicates the most recent = SEQ#, is not up-to-date. How does iTIP handle this? Or am I missing something? Please comment! Regards, Shriram V. ------=_NextPart_000_008D_01C3B521.4EB4B600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
 
I want to know how out of sequence = ADD=20 messages is handled.
 
Suppose that a user has an event with = SEQ #1 in his=20 store.
Now if ADD with SEQ#3 comes up, = what should be=20 done?
Since the received SEQ# > current = SEQ#, this is=20 a more recent ADD.
 
At this point if I accept ADD#3 as = update, the SEQ#=20 of the event in my calendar would increase to #3.
Next when older ADD#2 (or any other=20 method) arrives, it will be rejected, since SEQ# < current=20 SEQ#.
 
In effect, user's version of = vevent, although=20 indicates the most recent SEQ#, is not up-to-date.
How does iTIP handle this? Or am I = missing=20 something?
 
Please comment!
 
 
Regards,
Shriram V.
 
 
------=_NextPart_000_008D_01C3B521.4EB4B600-- From owner-ietf-calendar@mail.imc.org Fri Nov 28 14:57:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08336 for ; Fri, 28 Nov 2003 14:57:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASJftib041240 for ; Fri, 28 Nov 2003 11:41:55 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASJfs6C041239 for ietf-calendar-bks; Fri, 28 Nov 2003 11:41:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASJfrib041234 for ; Fri, 28 Nov 2003 11:41:53 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:pHDiPhqay8rrqDP5vTMk5YoVkSxUTUFF@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hASJfqaM006188 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 28 Nov 2003 11:41:54 -0800 Message-ID: <3FC7A4FF.4090805@Royer.com> Date: Fri, 28 Nov 2003 12:41:51 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: How to handle out-of-sequence ADDs. References: <009001c3b4f3$37103ed0$2a01a8c0@persistent.co.in> In-Reply-To: <009001c3b4f3$37103ed0$2a01a8c0@persistent.co.in> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010905050009070800060105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010905050009070800060105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Shriram V wrote: > Hi all, > > > I want to know how out of sequence ADD messages is handled. > > Suppose that a user has an event with SEQ #1 in his store. > Now if ADD with SEQ#3 comes up, what should be done? > Since the received SEQ# > current SEQ#, this is a more recent ADD. > At this point if I accept ADD#3 as update, the SEQ# of the event in my > calendar would increase to #3. > Next when older ADD#2 (or any other method) arrives, it will be > rejected, since SEQ# < current SEQ#. > In effect, user's version of vevent, although indicates the most > recent SEQ#, is not up-to-date. > How does iTIP handle this? Or am I missing something? Per iTIP: REFRESH A request is sent to an "Organizer" by an "Attendee" asking for the latest version of an event to be resent to the requester. and: The "UID" must be that of the existing event. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VEVENT". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". In effect the recipient does not have the current UID object, so send a REFRESH to get the latest copy. What is received should be #3 or bigger. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010905050009070800060105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI4MTk0MTUxWjAjBgkqhkiG9w0BCQQxFgQUFyK2+3hzu9bg26Yxzi2C tZzBHygwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAtRMOvkPaVoKM6ArZkivdYh1nWXEyQVmRdGQr49RrlN0xtTkBerUjmXYEXMTLfbkZ 1coF2lVIFmqUiG5e3g5A+7ybEIzTWI68Ijf7Kv89oZ7AI58Ul1YUi2r6RxRaJG7lmsLFP7dY GrQlwLwX8DM/Ua66+i8AdZUrDHgIGspLFIpfXSwVn3UVfOJq3IpOuKGhzNZlNEGc6toPnmVR 1p64z1+F/OaomfNKfxhBiiGmysQAu3X2ec/+w0V6lUKQEmPnWGBrwx2EQGBpgzAwMgyzxK0K mjBmpXd/no+SVdvHVygkRYQUsCnP3NM+OvenLG5IadG6wr0JfFuDybZii8QZaAAAAAAAAA== --------------ms010905050009070800060105-- From owner-ietf-calendar@mail.imc.org Fri Nov 28 15:13:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09687 for ; Fri, 28 Nov 2003 15:13:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASJvMib041653 for ; Fri, 28 Nov 2003 11:57:22 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASJvMNs041652 for ietf-calendar-bks; Fri, 28 Nov 2003 11:57:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASJvKib041644 for ; Fri, 28 Nov 2003 11:57:21 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:GXTuKQYC88bIDIfatU5SJLpMHZEmTnwt@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hASJvKaM006374 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 28 Nov 2003 11:57:21 -0800 Message-ID: <3FC7A89F.5090904@Royer.com> Date: Fri, 28 Nov 2003 12:57:19 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Clarification for Free/Busy References: <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> <5.2.1.1.0.20031124225554.00a26110@mail.comcast.net> <5.2.1.1.0.20031126224015.00a40a60@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031126224015.00a40a60@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040400080608030405080304" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040400080608030405080304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > > Second - to clarify one thing, the "not there" column means that the > STATUS property of the VEVENT is not present, I was trying to provide > for the case where we could not determine the status from the property. > > Third - since the Free/Busy query is directed toward one explicit > calendar UID, I'm not sure we need to worry about attendee PARTSTAT - > aren't we really querying the free/busy times on that VCALENDAR/VAGENDA ? > > Fourth- I'm willing to accept that OPAQUE+CONFIRMED = BUSY instead of > BUSY-UNAVAILABLE as Dan Winship stated, but then where do > BUSY-UNAVAILABLE statuses come from - other parts of a CUA that "know" > my normal working hours? In my use of my calendaring software at work, > I have to schedule my vacation time on my calendar. I don't know how > I'd indicate that to my software to return that as BUSY-UNAVAILABLE. > Not saying it can't be done; I'm just unclear about where it comes from. There is no predefined place it comes from. It is simply defended as time that can not be scheduled. Perhaps it is a resource calendar that is off line for some specifically unspecified reason. > Fifth- if an attendee has declined an invitation then the time on > their calendar should be FREE if (and only if) there is no other > VEVENT in that time period. There is no predefined rule, it is up to the implementations which may have its own reasons. Why do you think there has to be a predefined rule? > Sixth- this is for automated Free/Busy replies to a query, not to > publishing free/busy time since that publishing effort could be done > by any number of things. I do not think that we can predefine what the rule is for calculating the BUSY-UNAVAILABLE time. We simply have to define that what is returned is the BUSY-UNAVALIABLE time. What is returned for a company car calendar may have hard coded that 1/2 a day after a multi day usage the car is always unavailable (perhaps for inspection, service, or whatever). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040400080608030405080304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI4MTk1NzE5WjAjBgkqhkiG9w0BCQQxFgQUY3JyPrbWyqO4KxHdoS1j 4Lp5UmswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA4NG/4QTak4EkbJsY0LVsuFTkLSe8JgeItsjBM/02VrNBdiMtSbOeJqxw1Ulpt2qm 4/p97cYayqSRXmiKUNuhTjqrHBP2AkbKpgcDNNpIudiTgVTSbocRgamzCwl5KZCmZBl42/zf sFPl3FuFcSCDA7GVOkL7jStHpanx/L1eVcHYL2vIcmyAy8mn1Pmv/C4ItJOnW1pkHHEo0MS0 edBiVMeJK83Qp12IZIB0FST4Myb3Hvgg+bYPPUAOPs2NtjTyj+xLll22TfTFUEqJ+eIF6VZZ 3zb21+vUtvwjfZPO7jC3DCiqEPBaYAoTmTjgXlqCqsTwOLvWKJvQfKZH4xnUAQAAAAAAAA== --------------ms040400080608030405080304-- From owner-ietf-calendar@mail.imc.org Fri Nov 28 15:32:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10277 for ; Fri, 28 Nov 2003 15:32:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASKL1ib042618 for ; Fri, 28 Nov 2003 12:21:01 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hASKL1bf042617 for ietf-calendar-bks; Fri, 28 Nov 2003 12:21:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hASKKwib042609 for ; Fri, 28 Nov 2003 12:20:59 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:LGSekECQ+gIUsRpofmq3RtZFDVWJ2DUC@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id hASKKwaM006785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 28 Nov 2003 12:20:59 -0800 Message-ID: <3FC7AE2A.6010206@Royer.com> Date: Fri, 28 Nov 2003 13:20:58 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: an idea as an alternative to stored queries References: <5.2.1.1.0.20031120220448.00a427b0@mail.comcast.net> <5.2.1.1.0.20031126230935.00a499d0@mail.comcast.net> In-Reply-To: <5.2.1.1.0.20031126230935.00a499d0@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030906030708010102050001" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030906030708010102050001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > > The timezone issue does need to be handled, however it's probably > pretty easy: In my opinion if the client sends its current timezone > along with the date on the GET-TODAY command (or the date/time of the > GET-NEXT command), the server should return the responses translated > to that timezone if necessary. If the client sends no timezone, the > server should send whatever timezone is in the component. Also, if no > date or date/time value is sent, the server should use its local clock > to supply those values. The CUA timezone is passed down in the CUA capability reply. Lets just use that. > The reason I suggested dropping stored queries was because we never > reached consensus, that I can tell, about how such items would be > implemented; my suggestion was to provide some of the function that > stored queries were supposed to provide in a simpler manner that would > allow the CAP draft to be finished; stored queries can always be > designed and included in a future revision to the protocol if people > feel the work is worth it. Part of the merging of ideas over the last few years (and note that stored queries have been in CAP since it inception and in -00 of CAP). Included compromises. One of those compromises was stored queries. As with any component the CS can have VCARs that do no permit them to stored. But the conversations were to allow them exist. > I have, as yet, been unable to think of other commands that would be > as useful, or as commonly used. If anyone else has good ones to > propose, I do believe that they should be the types of commands that > are short and quick like to two above, with minimal client > modification required. The most basic use case I can think of is a > device with programming in ROM whose function is to download today's > information and display it - the entire function, in CAP, would be > ROMable using the GET-TODAY command with no timezone and no date > passed, yet it could still retrieve the up-to-date information. -- Predefining what they are is not the same issue as defining that they can exist. Some enterprise vendors do not want them because they are not concerted with bandwidth. PDA and CELL vendors will do them anyway because they (or their customer) has to pay $$$ for air time if they do not exist. So the compromise was that we would define how to store them. And again, a CS is free to VCAR them to permission denied for a specific implementation as one could do for any other component. What user/vendor-A wants back may not be the same as what user/vendor-B's cell phone is even capable of handling. A might not be able to handle VJOURNAL - so why pay for the bandwidth to transfer them. They do not need to be predefined. Just a standard way for them to be stored so that when vendor-C does a query all from VAGENDA they will know what it is and if it can ignore them. It is not as if a CS is going to allow all random CUAs to deposit stored queries in any random calendar within its store any more than the CS would allow a random CUA to deposit booked entries in any random calendar. We concluded during the original debates that trying to predefine the exact query in advance was not going to work as that depended on the target CUA and its target customers. So we agreed that they could be stored and that as VCAR's would limit them to the owner, they would be known to the owners CUA(s), no mysterious object types to guess at by non-same-vendor CUA's as they all would be the same component type (VQUERY) . Ether the CUA knew what XXX did or not. Ether you were allowed (by VCAR like any other component) to modify it, remove it, add one, or not. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030906030708010102050001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDMxMTI4MjAyMDU4WjAjBgkqhkiG9w0BCQQxFgQUggr0NSfZVzmCUS4I4Gsz 8+n/s8YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAX+GkcmIz1L/2Dy3tcqSSaDD3iUmGMQbDDg9LONqZE91umsbQLgi71DWOLj4uKpIw udWfO4YK1surc1Kgk19kaEJjJLxqTeQb29gA2XC5IQMd4ANTp3F9nXgHqFRdTOtMd/GRtCIo 6crdy7vnakgMlt3tT0jMA8A0PBHVkWH7+tpZxwsrHxzrunGn+ngBYknT6V8HEyo9HEcZotF0 G4wCWPySSjKUF6kJ5RuEklrn243PImbTR4hpgGR2H5vmpDVvglN4y0h9Ft3/BX4LKfK1HgCV 8/3Z/c1M0uSHsLXzLT6zBGWvJvvPlz7U0OmfBiEuFH6QgCAfedgkHzEnKjZ0aQAAAAAAAA== --------------ms030906030708010102050001--