From owner-ietf-calendar@mail.imc.org Tue Apr 1 11:15:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25431 for ; Tue, 1 Apr 2003 11:15:19 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31FoWJM005084 for ; Tue, 1 Apr 2003 07:50:32 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31FoWuP005083 for ietf-calendar-bks; Tue, 1 Apr 2003 07:50:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31FoVJM005079 for ; Tue, 1 Apr 2003 07:50:31 -0800 (PST) In-Reply-To: <3E88ADE1.20607@centive.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 1 Apr 2003 10:49:52 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/01/2003 10:50:30 AM, Serialize complete at 04/01/2003 10:50:30 AM Content-Type: multipart/alternative; boundary="=_alternative 0056B15585256CFB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056B15585256CFB_= Content-Type: text/plain; charset="US-ASCII" John replied on 03/31/2003 04:06:41 PM: > VFREEBUSY on the fly, in response to a query. That'll complicate access > control; do we have a way to say "Joe can't read my calendar, but he can > read my freebusy"? Yep. From Section 4.2.2. Predefined VCARs: Predefined calendar access CARIDs that MUST BE implemented are: CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules that allow UPNs to search "VFREEBUSY" components. An example definition for this VCAR is: BEGIN:VCAR CARID:READBUSYTIMEINFO BEGIN:VRIGHT GRANT:* PERMISSION:SEARCH SCOPE:SELECT * FROM VFREEBUSY END:VRIGHT END:VCAR and in Section 8.14. DEFAULT-VCARS Property: Property Name: DEFAULT-VCARS Purpose: This property is used to specify the "CARID" property ids of the default "VCAR" components for newly created "VAGENDA" components. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST BE specified in "VCALSTORE" calendar component and MUST at least specify the following values: "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and "DEFAULTOWNER". so all CAP 1.0 implemenations MUST have this ablity/feature. 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 0056B15585256CFB_= Content-Type: text/html; charset="US-ASCII"
John replied on 03/31/2003 04:06:41 PM:
> VFREEBUSY on the fly, in response to a query.  That'll complicate access
> control; do we have a way to say "Joe can't read my calendar, but he can
> read my freebusy"?

Yep.  From Section 4.2.2. Predefined VCARs:

Predefined calendar access CARIDs that MUST BE implemented are:

CARID:READBUSYTIMEINFO -
Specifies the "GRANT" and "DENY" rules that allow UPNs to search "VFREEBUSY" components. An example definition for this VCAR is:

BEGIN:VCAR
CARID:READBUSYTIMEINFO
BEGIN:VRIGHT
GRANT:*
PERMISSION:SEARCH
SCOPE:SELECT * FROM VFREEBUSY
END:VRIGHT
END:VCAR

and in Section 8.14. DEFAULT-VCARS Property:

Property Name: DEFAULT-VCARS

Purpose: This property is used to specify the "CARID" property ids of the default "VCAR" components for newly created "VAGENDA" components.

Value Type: TEXT

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

Conformance: This property MUST BE specified in "VCALSTORE" calendar component and MUST at least specify the following values: "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and "DEFAULTOWNER".

so all CAP 1.0 implemenations MUST have this ablity/feature.

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 0056B15585256CFB_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 11:56:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29138 for ; Tue, 1 Apr 2003 11:56:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUhJM007679 for ; Tue, 1 Apr 2003 08:30:43 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31GUhOv007678 for ietf-calendar-bks; Tue, 1 Apr 2003 08:30:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GUfJM007667 for ; Tue, 1 Apr 2003 08:30:42 -0800 (PST) In-Reply-To: <3E88CB76.7020703@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 1 Apr 2003 11:27:19 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/01/2003 11:30:39 AM, Serialize complete at 04/01/2003 11:30:39 AM Content-Type: multipart/alternative; boundary="=_alternative 005A1F5205256CFB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A1F5205256CFB_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 03/31/2003 06:12:54 PM: > > For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or > > METHOD:REPLY for requesting and responding, respectively. In CAP, I > > guess that would crudely map to a CREATE command with particular TARGETs > > but there is NOTHING to lead me to belive that the CS must do any actual > > processing beyond the actual request creation. > > In fact we squashed the CS from doing any work for the CUA. > You need to have your CUA or a CUA-BOT do it for you. I dont recall that decision and I certainly think making VFREEBUSY data totally disjoint from the contents of the associated calendar is a BAD idea. It makes busytime useless if we have no clear and consistant design for doing busytime lookups and now busytime data is maintained. How can any CU reasonably expect to do any kind of scheduling with other users if busytime information is NOT guaranteed to be in sync w/the calendar contents (or reasonably close to it assuming some lag in updating)? We already mandate that a CS MUST provide support for a READBUSYTIMEINFO VCAR so its reasonable to expect that the CS would maintain that busytime info rather than relying on CUAs to do this maintenance or some totally unspecified "Bot" mechanism. After all, since VFREEBUSY have NO linkage information to the actual entries in a calendar (go recheck 2445 if you dont believe me, Section 4.6.4 Free/Busy Component) there is very little chance that a CUA can properly maintain the 'digested' info in a VFREEBUSY. And making the prescious 'thin' clients The only reasonble source for keeping the VFREEBUSY accurate is to have it done by the CS as changes are made to the calendar. _Assuming_ that an unspecified "Bot" mechanism is the way that it should/would/MAY be done is NOT sufficient here if we want that key functionality in CAP. CAP 1.0 needs to provide that basic functionality in it or we severly risk loosing user adoption. > > Actually it is not. The only ANBF in SEARCH is: > > Read more text...: > > comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" > / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" > / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" > / x-comp / iana-comp > > > And comp-name is used in: > > cal-query = "SELECT" SP cap-val SP > "FROM" SP comp-name SP > "WHERE" SP cap-expr > Umm, sorry but that ABNF is NOT under SEARCH. That ABNF is part of Section 6.1.1. CAL-QUERY Value Type which is concerned with "Registration of text/calendar MIME value type CAL-QUERY" Perhaps you meant to say "SELECT" instead of SEARCH..?? A cal-query data type is used for the QUERY (Section 8.26), RESTRICTION (Section 8.33) and SCOPE (Section 8.34) properties. The latter 2 are related to VCARs. The former appears ONLY referenced in the ABNF for the VQUERY component (Section 9.6). If you recheck your draft you will find that the ONLY references to a VQUERY component usage is in the CREATE command: create-comp = agendac / carc / queryc / timezonec / freebusyc / eventc / todoc / journalc / iana-comp / x-component NOWHERE else in the ABNF do I find any reference to the queryc. As such it is illegal for me to use a VQUERY in any other command OTHER than a CREATE one (a comment I made many moon ago but must have been forgotten). Then again, the create-object in the ABNF is referenced NOWHERE in the draft either so something is either very wrong w/the find text feature of MSIE or there is some really bad ABNF here... However this is a topic for a new thread I think... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005A1F5205256CFB_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 03/31/2003 06:12:54 PM:
> > For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or
> > METHOD:REPLY for requesting and responding, respectively.  In CAP, I
> > guess that would crudely map to a CREATE command with particular TARGETs
> > but there is NOTHING to lead me to belive that the CS must do any actual
> > processing beyond the actual request creation.  
>
> In fact we squashed the CS from doing any work for the CUA.
> You need to have your CUA or a CUA-BOT do it for you.
I dont recall that decision and I certainly think making VFREEBUSY data totally disjoint from the contents of the associated calendar is a BAD idea.  It makes busytime useless if we have no clear and consistant design for doing busytime lookups and now busytime data is maintained.  

How can any CU reasonably expect to do any kind of scheduling with other users if busytime information is NOT guaranteed to be in sync w/the calendar contents (or reasonably close to it assuming some lag in updating)?

We already mandate that a CS MUST provide support for a READBUSYTIMEINFO VCAR so its reasonable to expect that the CS would maintain that busytime info rather than relying on CUAs to do this maintenance or some totally unspecified "Bot" mechanism.   After all, since VFREEBUSY have NO linkage information to the actual entries in a calendar (go recheck 2445 if you dont believe me, Section 4.6.4 Free/Busy Component) there is very little chance that a CUA can properly maintain the 'digested' info in a VFREEBUSY.    And making the prescious 'thin' clients

The only reasonble source for keeping the VFREEBUSY accurate is to have it done by the CS as changes are made to the calendar.  _Assuming_ that an unspecified "Bot" mechanism  is the way that it should/would/MAY be done is NOT sufficient here if we want that key functionality in CAP.  CAP 1.0 needs to provide that basic functionality in it or we severly risk loosing user adoption.

> > Actually it is not.  The only ANBF in SEARCH is:
>
> Read more text...:
>
>       comp-name  = "VEVENT"  / "VTODO"     / "VJOURNAL" / "VFREEBUSY"
>                  / "VALARM"  / "DAYLIGHT"  / "STANDARD" / "VAGENDA"
>                  / "VCAR"    / "VCALSTORE" / "VQUERY"   / "VTIMEZONE"
>                  / x-comp    / iana-comp
>
>
> And comp-name is used in:
>
>    cal-query  = "SELECT"   SP   cap-val  SP
>                 "FROM"     SP   comp-name SP
>                 "WHERE"    SP   cap-expr
>

Umm, sorry but that ABNF is NOT under SEARCH.   That ABNF is part of Section 6.1.1. CAL-QUERY Value Type which is concerned with "Registration of text/calendar MIME value type CAL-QUERY"

Perhaps you meant to say "SELECT" instead of SEARCH..??

A cal-query data type is used for the QUERY (Section 8.26), RESTRICTION (Section 8.33) and SCOPE (Section 8.34) properties.  The latter 2 are related to VCARs.  The former appears ONLY referenced in the ABNF for the VQUERY component (Section 9.6).  If you recheck your draft you will find that the ONLY references to a VQUERY component usage is in the CREATE command:

 create-comp = agendac / carc / queryc
              / timezonec / freebusyc
              / eventc / todoc / journalc
              / iana-comp / x-component
NOWHERE else in the ABNF do I find any reference to the queryc.   As such it is illegal for me to use a VQUERY in any other command OTHER than a CREATE one (a comment I made many moon ago but must have been forgotten).  

Then again, the create-object in the ABNF is referenced NOWHERE in the draft either so something is either very wrong w/the find text feature of MSIE or there is some really bad ABNF here...  However this is a topic for a new thread I think...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005A1F5205256CFB_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 12:01:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29438 for ; Tue, 1 Apr 2003 12:01:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GhWJM008163 for ; Tue, 1 Apr 2003 08:43:32 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31GhWUR008162 for ietf-calendar-bks; Tue, 1 Apr 2003 08:43:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GhVJM008158 for ; Tue, 1 Apr 2003 08:43:31 -0800 (PST) In-Reply-To: <3E88B003.40606@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 1 Apr 2003 11:43:30 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/01/2003 11:43:27 AM, Serialize complete at 04/01/2003 11:43:27 AM Content-Type: multipart/alternative; boundary="=_alternative 005B9AB105256CFB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B9AB105256CFB_= Content-Type: text/plain; charset="US-ASCII" Doug responsed on 03/31/2003 04:15:47 PM: > > I may infer from the text under CREATE that I (or my CUA) must CREATE > > the VFREEBUSY for it to exist (see create-vreply and create-comp). > > Yes. Umm, why should I (a CUA) be able to do that? Having VFREEBUSY info unrepresentable of the actual calendar data makes it useless for its intended purpose. There is NO reasonable way that any CUA can update the VFREEBUSY info to reflect a new change short of rewritting it ALL over! If you check the ABNF for VFREEBUSY you will see that it contains minimal info: freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF fbprop "END" ":" "VFREEBUSY" CRLF fbprop = *( ; the following are optional, ; but MUST NOT occur more than once contact / dtstart / dtend / duration / dtstamp / organizer / uid / url / ; the following are optional, ; and MAY occur more than once attendee / comment / freebusy / rstatus / x-prop ) and certainly NOTHING that would allow a CUA to pick and choose which FREEBUSY property to change/remove/add. As such ALL CUAs would have to totally rewrite the VFREEBUSY info each and every time. Sounds really efficient, even for 'fat' clients. Im sure PDAs have the horsepower and bandwidth to do this updating often too... FYI: the UID property is NOT the UID of the 'related' entry in the FREEBUSY property, it is the UID matching the UID of the REQUEST. It was put there for iTIP messaging only, NOT for associating the FREEBUSY property to a particular calendar entry! Also there can be multiple FREEBUSY properties that are an amalgam of several entries (ie: Merge my 3 back to back to back meetings into 1 FREEBUSY representative of the combined time slice) so its not valid to assume a 1 to 1 mapping in CAP. > TRANSPARENT entries will also not show up in your VFREEBUSY. Why not!? Recheck 2445, the ABNF for a FREEBUSY property is (minor text edits applied for alignment): freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF fbparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" fbtypeparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) fbtypeparam = "FBTYPE" "=" ( "FREE" / "BUSY" / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" / x-name / ; Some experimental iCalendar data type iana-token ) so its perfectly legal (and useful!) to send back "Im pencilled in from 3-3:30 tomorrow" so that the requestor knows you have some thing 'tentative' on your calendar already. BTW: CAP needs to add some prose to reflect the new values for TRANSP defined in Section 8.37 so that the fbparam properly conveys that TRANSParency status. 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 005B9AB105256CFB_= Content-Type: text/html; charset="US-ASCII"
Doug responsed on 03/31/2003 04:15:47 PM:
> > I may infer from the text under CREATE that I (or my CUA) must CREATE
> > the VFREEBUSY for it to exist (see create-vreply and create-comp).  
>
> Yes.
Umm, why should I (a CUA) be able to do that?  Having VFREEBUSY info unrepresentable of the actual calendar data makes it useless for its intended purpose.

There is NO reasonable way that any CUA can update the VFREEBUSY info to reflect a new change short of rewritting it ALL over!  If you check the ABNF for VFREEBUSY you will see that it contains minimal info:

     freebusyc  = "BEGIN" ":" "VFREEBUSY" CRLF
                 fbprop
                 "END" ":" "VFREEBUSY" CRLF

    fbprop     = *(

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

               contact / dtstart / dtend / duration / dtstamp /
               organizer / uid / url /

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

               attendee / comment / freebusy / rstatus / x-prop

               )

and certainly NOTHING that would allow a CUA to pick and choose which FREEBUSY property to change/remove/add.  As such ALL CUAs would have to totally rewrite the VFREEBUSY info each and every time.  Sounds really efficient, even for 'fat' clients.  Im sure PDAs have the horsepower and bandwidth to do this updating often too...

FYI: the UID property is NOT the UID of the 'related' entry in the FREEBUSY property, it is the UID matching the UID of the REQUEST.  It was put there for iTIP messaging only, NOT for associating the FREEBUSY property to a particular calendar entry!  Also there can be multiple FREEBUSY properties that are an amalgam of several entries (ie: Merge my 3 back to back to back meetings into 1 FREEBUSY representative of the combined time slice) so its not valid to assume a 1 to 1 mapping in CAP.

> TRANSPARENT entries will also not show up in your VFREEBUSY.
Why not!? Recheck 2445, the ABNF for a FREEBUSY property is (minor text edits applied for alignment):

     freebusy   = "FREEBUSY" fbparam ":" fbvalue CRLF

    fbparam    = *(
               ; the following is optional,
               ; but MUST NOT occur more than once

               (";" fbtypeparam) /

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

               (";" xparam)

               )

     fbtypeparam  = "FBTYPE" "="
                (
                "FREE" /
                "BUSY" /
                "BUSY-UNAVAILABLE" /
                "BUSY-TENTATIVE" /
                x-name /                ; Some experimental iCalendar data type
                iana-token
                )

so its perfectly legal (and useful!) to send back "Im pencilled in from 3-3:30 tomorrow" so that the requestor knows you have some thing 'tentative' on your calendar already.

BTW: CAP needs to add some prose to reflect the new values for TRANSP defined in Section 8.37 so that the fbparam properly conveys that TRANSParency status.

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 005B9AB105256CFB_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 12:45:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03437 for ; Tue, 1 Apr 2003 12:45:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HTbJM009489 for ; Tue, 1 Apr 2003 09:29:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31HTbhB009488 for ietf-calendar-bks; Tue, 1 Apr 2003 09:29:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h31HTZJM009482 for ; Tue, 1 Apr 2003 09:29:36 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040112340417156 for ; Tue, 01 Apr 2003 12:34:04 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Apr 2003 12:27:20 -0500 Message-ID: <3E89CBF8.1030405@centive.com> Date: Tue, 01 Apr 2003 12:27: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: CAP & busytime? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2003 17:27:20.0412 (UTC) FILETIME=[F326A9C0:01C2F873] 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: > Having VFREEBUSY info unrepresentable of the actual calendar data > makes it useless for its intended purpose. Actually, on reflection, I'm not sure that's so. There could be calendar events that one doesn't want exposed in one's VFREEBUSY; having the CUA compile the VFREEBUSY instead of the CS allows us to separate mechanism and policy, and move the policy component down towards the user. However, this is an edge case, and the costs seem pretty high. Consider this: if VFREEBUSY is compiled by the CUA, is there only one per user? Neither possibility is very appealing. If there are multiples, then someone trying to schedule an event in a particular period may have to fetch each VFREEBUSY that overlaps that period, and combinet hem. If there's only one, then anybody trying to schedule with a user is going to get their *entire* VFREEBUSY, probably including all events from the time the VFREEBUSY was created until some arbitrary end date (there has to be an end date, because VFREEBUSY doesn't have repeats); that could be huge. If the VFREEBUSY were compiled on the fly by the CS (which should be a fairly cheap operation), then the requesting CUA could specify the period of interest, and get just the data it needs. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 1 14:36:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09829 for ; Tue, 1 Apr 2003 14:36:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JCIJM014286 for ; Tue, 1 Apr 2003 11:12:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JCH8e014285 for ietf-calendar-bks; Tue, 1 Apr 2003 11:12:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JCGJM014281 for ; Tue, 1 Apr 2003 11:12:16 -0800 (PST) In-Reply-To: <3E89CBF8.1030405@centive.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 1 Apr 2003 14:07:09 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/01/2003 02:12:05 PM, Serialize complete at 04/01/2003 02:12:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0068C0F885256CFB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068C0F885256CFB_= Content-Type: text/plain; charset="US-ASCII" John replied on 04/01/2003 12:27:20 PM: > > Having VFREEBUSY info unrepresentable of the actual calendar data > > makes it useless for its intended purpose. > > Actually, on reflection, I'm not sure that's so. There could be > calendar events that one doesn't want exposed in one's VFREEBUSY; having > the CUA compile the VFREEBUSY instead of the CS allows us to separate > mechanism and policy, and move the policy component down towards the user. And make each CUA consume even more cycles rebuilding VFREEBUSY data and resending it. Hmm, lets weigh that against having the CS do it automatically at a reduced cost in CUA load (thus better CUA performance) and network bandwidth in addition to the CS resources consumed to just deal with the added traffic. Im sure that every 'thin' client author is very anxious to make sure they also design their CUA so that it can _properly_ update the VFREEBUSY info too... Then again maybe they will forgoe that and thin client CUs will just have no busytime to return... VFREEBUSY is not a policy issue unless you are talking about READBUSYTIMEINFO VCARs. VFREEBUSY data is intended to be: Purpose: Provide a grouping of component properties that describe either a request for free/busy time, describe a response to a request for free/busy time or describe a published set of busy time. The jist of my first posting is that in CAP it is unclear just how busytime is looked up in real time. In particular I find that CAP does not "specifies how to search for available busy time information" as promised in the 1st paragraph of Section 1. Or at least it does not do it in a clear and unambiguious manner that I can understand. In addition if you think there is a compelling need to have some TRANSparent property value that means "This entry is NOT to be represented in any VFREEBUSY property." then you'd better suggest some prose for it and some good motivation. I for one think that such a case is very outside the norms of the day to day work environments that our target users live in. By the combination of VCARs and TRANS properties I think that "That that need to see my busytime can, those that do not get nothing" can be achieved, even for your seemingly rare case. > However, this is an edge case, and the costs seem pretty high. I agree. > Consider > this: if VFREEBUSY is compiled by the CUA, is there only one per user? Per 2445 there can be multiple ways of storing VFREEBUSY data (one or multiple VFREEBUSYs with one or mulitple FREEBUSY properties). The more vexing case is does the CUA have ALL the calendar data necessary to properly regenerate VFREEBUSY every time it makes an update to the TARGET calendar? Maybe, maybe not. Still all this assumes we have some clear and consistant manner for easily getting the busytime for a user or set of users and I have yet to see it specified in CAP. Hence my starting this thread.... > If there are multiples, then > someone trying to schedule an event in a particular period may have to > fetch each VFREEBUSY that overlaps that period, and combinet hem. Already a requirement of 2445, Section 4.6.4: Multiple "VFREEBUSY" calendar components can be specified within an iCalendar object. This permits the grouping of Free/Busy information into logical collections, such as monthly groups of busy time information. [Snip] Free/Busy information is represented with the "FREEBUSY" property. This property provides a terse representation of time periods. One or more "FREEBUSY" properties can be specified in the "VFREEBUSY" calendar component. so its perfectly possible that a response may have 1 VFREEBUSY with multiple FREEBUSY properties OR it can have multiple VFREEBUSYs with 1 or more FREEBUSY properties in it. In order to make life a little easier on the recipient of said data there we added this to the definition of the FREEBUSY property: "FREEBUSY" properties within the "VFREEBUSY" calendar component SHOULD be sorted in ascending order, based on start time and then end time, with the earliest periods first. so the CUA may be able to assume that once it finds a FREEBUSY in a VFREEBUSY that is after its interest date it can stop parsing the rest of the FREEBUSYs and go on to the next VFREEBUSY. (It may also want to just keep parsing but thats an implimentation detail really). > If > there's only one, then anybody trying to schedule with a user is going > to get their *entire* VFREEBUSY, probably including all events from the > time the VFREEBUSY was created until some arbitrary end date (there has > to be an end date, because VFREEBUSY doesn't have repeats); that could > be huge. Whoa Hoss! You may want to refresh yourself on busytime searchign in 2445. From Section 4.6.4 again: When used to request free/busy time information, the "ATTENDEE" property specifies the calendar users whose free/busy time is being requested; the "ORGANIZER" property specifies the calendar user who is requesting the free/busy time; the "DTSTART" and "DTEND" properties specify the window of time for which the free/busy time is being requested; so the CUA can selectively bound the search range to be "Today @ 9AM thru Today @ 4:30PM" and it is expected that the response would only contain data for that range of time. As such the CUA wont have to sort thru all the VFREEBUSY data for my entire calendar starting back in 1996 thru 2045 (dont ask!); it should only be getting the data for the specified DTSTART/DTEND/DURATION range. > If the VFREEBUSY were compiled on the fly by the CS (which should be a > fairly cheap operation), then the requesting CUA could specify the > period of interest, and get just the data it needs. True. If the CS actually stored the data in an index of some kind (cough, SQL table?, cough) then it may even be faster than if the data were generated dynamically. It kinda depends on how tricky we allow busytime querying to become. For example: just a simple date/time bounded range or do we allow querying based on entry criteria too!? I for one say date/time bounding ONLY... I still have more than a little concern that any CUA could just go muck in the VFREEBUSY data and make it totally unpresentative of the actual calendars status. I also find that other concepts like moving VFREEBUSY data around somewhat useless at best and erroneous at worse. Still my first concern is still just how a CUA is supposed to query for busytime in CAP. Doug has suggested that its just like in iTIP where the METHOD:REQUEST is sent out and then at some point later a METHOD:REPLY returns. However this really describes a store and forward model of processing what is essentialy a realtime action. The response to the CREATE of the METHOD:REQUEST is "Ok, I created your VFREEBUSY REQUEST" and then the CUA has to poll some UNDETERMINED location presumably using the SEARCH command for some VFREEBUSY REPLY. However just where this SEARCH would look is unspecified. I also think that treating a busytime request like a mail message essentialy is the wrong approach to take. Then again I could just be misreading Dougs responses... Am I alone or does anyone else share my confusion? 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 0068C0F885256CFB_= Content-Type: text/html; charset="US-ASCII"
John replied on 04/01/2003 12:27:20 PM:
> > Having VFREEBUSY info unrepresentable of the actual calendar data
> > makes it useless for its intended purpose.
>
> Actually, on reflection, I'm not sure that's so.  There could be
> calendar events that one doesn't want exposed in one's VFREEBUSY; having
> the CUA compile the VFREEBUSY instead of the CS allows us to separate
> mechanism and policy, and move the policy component down towards the user.
And make each CUA consume even more cycles rebuilding VFREEBUSY data and resending it.  Hmm, lets weigh that against having the CS do it automatically at a reduced cost in CUA load (thus better CUA performance) and network bandwidth in addition to the CS resources consumed to just deal with the added traffic.  

Im sure that every 'thin' client author is very anxious to make sure they also design their CUA so that it can _properly_ update the VFREEBUSY info too...  Then again maybe they will forgoe that and thin client CUs will just have no busytime to return...

VFREEBUSY is not a policy issue unless you are talking about READBUSYTIMEINFO VCARs.  VFREEBUSY data is intended to be:

   Purpose: Provide a grouping of component properties that describe
  either a request for free/busy time, describe a response to a request
  for free/busy time or describe a published set of busy time.

The jist of my first posting is that in CAP it is unclear just how busytime is looked up in real time.  In particular I find that CAP does not "specifies how to search for available busy time information" as promised in the 1st paragraph of Section 1.  Or at least it does not do it in a clear and unambiguious manner that I can understand.

In addition if you think there is a compelling need to have some TRANSparent property value that means "This entry is NOT to be represented in any VFREEBUSY property." then you'd better suggest some prose for it and some good motivation.  I for one think that such a case is very outside the norms of the day to day work environments that our target users live in.  By the combination of VCARs and TRANS properties I think that "That that need to see my busytime can, those that do not get nothing" can be achieved, even for your seemingly rare case.

> However, this is an edge case, and the costs seem pretty high.  

I agree.

>                                                                 Consider
> this: if VFREEBUSY is compiled by the CUA, is there only one per user?

Per 2445 there can be multiple ways of storing VFREEBUSY data (one or multiple VFREEBUSYs with one or mulitple FREEBUSY properties).  The more vexing case is does the CUA have ALL the calendar data necessary to properly regenerate VFREEBUSY every time it makes an update to the TARGET calendar?  Maybe, maybe not.

Still all this assumes we have some clear and consistant manner for easily getting the busytime for a user or set of users and I have yet to see it specified in CAP.  Hence my starting this thread....

>                                            If there are multiples, then
> someone trying to schedule an event in a particular period may have to
> fetch each VFREEBUSY that overlaps that period, and combinet hem.

Already a requirement of 2445, Section 4.6.4:

                      Multiple "VFREEBUSY" calendar components can be
  specified within an iCalendar object. This permits the grouping of
  Free/Busy information into logical collections, such as monthly
  groups of busy time information.

[Snip]

   Free/Busy information is represented with the "FREEBUSY" property.
  This property provides a terse representation of time periods. One or
  more "FREEBUSY" properties can be specified in the "VFREEBUSY"
  calendar component.

so its perfectly possible that a response may have 1 VFREEBUSY with multiple FREEBUSY properties OR it can have multiple VFREEBUSYs with 1 or more FREEBUSY properties in it.

In order to make life a little easier on the recipient of said data there we added this to the definition of the FREEBUSY property:

   "FREEBUSY" properties within the "VFREEBUSY" calendar component
  SHOULD be sorted in ascending order, based on start time and then end
  time, with the earliest periods first.

so the CUA may be able to assume that once it finds a FREEBUSY in a VFREEBUSY that is after its interest date it can stop parsing the rest of the FREEBUSYs and go on to the next VFREEBUSY.  (It may also want to just keep parsing but thats an implimentation detail really).

>                                                                     If
> there's only one, then anybody trying to schedule with a user is going
> to get their *entire* VFREEBUSY, probably including all events from the
> time the VFREEBUSY was created until some arbitrary end date (there has
> to be an end date, because VFREEBUSY doesn't have repeats); that could
> be huge.
Whoa Hoss!  You may want to refresh yourself on busytime searchign in 2445.  From Section 4.6.4 again:

   When used to request free/busy time information, the "ATTENDEE"
  property specifies the calendar users whose free/busy time is being
  requested; the "ORGANIZER" property specifies the calendar user who
  is requesting the free/busy time; the "DTSTART" and "DTEND"
  properties specify the window of time for which the free/busy time is
  being requested;

so the CUA can selectively bound the search range to be "Today @ 9AM thru Today @ 4:30PM" and it is expected that the response would only contain data for that range of time.  

As such the CUA wont have to sort thru all the VFREEBUSY data for my entire calendar starting back in 1996 thru 2045 (dont ask!); it should only be getting the data for the specified DTSTART/DTEND/DURATION range.

> If the VFREEBUSY were compiled on the fly by the CS (which should be a
> fairly cheap operation), then the requesting CUA could specify the
> period of interest, and get just the data it needs.

True.  If the CS actually stored the data in an index of some kind (cough, SQL table?, cough) then it may even be faster than if the data were generated dynamically.  It kinda depends on how tricky we allow busytime querying to become.  For example: just a simple date/time bounded range or do we allow querying based on entry criteria too!?  I for one say date/time bounding ONLY...

I still have more than a little concern that any CUA could just go muck in the VFREEBUSY data and make it totally unpresentative of the actual calendars status.  I also find that other concepts like moving VFREEBUSY data around somewhat useless at best and erroneous at worse.  

Still my first concern is still just how a CUA is supposed to query for busytime in CAP.  Doug has suggested that its just like in iTIP where the METHOD:REQUEST is sent out and then at some point later a METHOD:REPLY returns.  However this really describes a store and forward model of processing what is essentialy a realtime action.  

The response to the CREATE of the METHOD:REQUEST is "Ok, I created your VFREEBUSY REQUEST" and then the CUA has to poll some UNDETERMINED location presumably using the SEARCH command for some VFREEBUSY REPLY.  However just where this SEARCH would look is unspecified.  I also think that treating a busytime request like a mail message essentialy is the wrong approach to take.  

Then again I could just be misreading Dougs responses...  Am I alone or does anyone else share my confusion?

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 0068C0F885256CFB_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 14:56:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10888 for ; Tue, 1 Apr 2003 14:56:19 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JZ9JM015178 for ; Tue, 1 Apr 2003 11:35:09 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JZ94I015177 for ietf-calendar-bks; Tue, 1 Apr 2003 11:35:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31JZ7JM015173 for ; Tue, 1 Apr 2003 11:35:07 -0800 (PST) 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 h31JZ3M4019737 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Apr 2003 11:35:08 -0800 Message-ID: <3E89E9DD.8030306@Royer.com> Date: Tue, 01 Apr 2003 12:34:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090404090300040106020305" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090404090300040106020305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 03/31/2003 06:12:54 PM: > > > For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or > > > METHOD:REPLY for requesting and responding, respectively. In CAP, I > > > guess that would crudely map to a CREATE command with particular > TARGETs > > > but there is NOTHING to lead me to belive that the CS must do any > actual > > > processing beyond the actual request creation. > > > > In fact we squashed the CS from doing any work for the CUA. > > You need to have your CUA or a CUA-BOT do it for you. > > I dont recall that decision and I certainly think making VFREEBUSY data > totally disjoint from the contents of the associated calendar is a BAD > idea. It was under the 'roll-up' discussion. Only you and I thought it was a good idea. The WG smashed it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090404090300040106020305 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDExOTM0NTRaMCMGCSqGSIb3DQEJBDEWBBS3 RRiwgTzPFzuHMEtDsyZptIHxpjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAiMRU2+IdpBzy sryLnB8cAwuchzBma8NoKWCRDcEgqoD35SjmYmy+gYN4jIlXZD5xYMxeLNtbgZzbW3X5rqjf s88nLIhheHxjcfyjhgEUFjp6NwXLbkAeGaKfqQzb/dQBvsHTjVasp61mffRMkCJvn46j8TLS bsGMyzlUPr3IXLeQIoYDC5Mz6+M3EVGwX6AYzgWeB0dZKL6X7nnP1MQgSqcXkUMGLEMtNN3y 5IhcYOeeIK/ehySlV84Oee65tFPSZLTZDjWlKRGGCpqTpIt1b6F7cc+8bn7bAEHvnD7IOpeM X4uVQD7ui2i/Iz2H6Pm9tK4Bux9XVUlQTBAiW3b5WAAAAAAAAA== --------------ms090404090300040106020305-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 15:15:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12883 for ; Tue, 1 Apr 2003 15:15:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JwIJM016127 for ; Tue, 1 Apr 2003 11:58:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JwIc8016126 for ietf-calendar-bks; Tue, 1 Apr 2003 11:58:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31JwHJM016119 for ; Tue, 1 Apr 2003 11:58:17 -0800 (PST) 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 h31JwFM4019963 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Apr 2003 11:58:18 -0800 Message-ID: <3E89EF4E.6080503@Royer.com> Date: Tue, 01 Apr 2003 12:58:06 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080305070900090605060204" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080305070900090605060204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > The only reasonble source for keeping the VFREEBUSY accurate is to have > it done by the CS as changes are made to the calendar. _Assuming_ that > an unspecified "Bot" mechanism is the way that it should/would/MAY be > done is NOT sufficient here if we want that key functionality in CAP. > CAP 1.0 needs to provide that basic functionality in it or we severly > risk loosing user adoption. Need told me and Pat repeated that we can not add features to CAP unless 20 people on this list insist tht it must be done. We are shipping CAP soon ! :-) I am in the processing of updating my CUA-BOT draft (never sent) as an add-on to CAP. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080305070900090605060204 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDExOTU4MDZaMCMGCSqGSIb3DQEJBDEWBBTZ tWOd542yInTFXTLQHevGY8l4cDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAcM0TKsv9yJ4a aCsm83mUuwvNBGsqIpIGdiyEcMK517pCc/2U3QUuQARxPeXPfs5RZMzNFv604fULKdYe22S1 JHgXZz6xyjtUbVXAWRi6nlEB8pXXqGwb8peOi78LIcedtNJaZAEJ/Wy/Z9umygD9KB84l4Xz T5o5AODov9EsI9hbuUbJh0rg+mtjRiDUgJMyzv2PC15u3NmD7dBHEXpFFcfNWbDFBMOcG2X1 tdLraCKgICO4wFNt0sXzQB/MxCFxaN0bKJZ9dpDSUpoHJeYt3V0Fw3Sa+gbIb6GBimVYPjbj y2EM82mowogtRerM490Mb6lkmIQhoG8kHy+r13kvoAAAAAAAAA== --------------ms080305070900090605060204-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 15:17:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13082 for ; Tue, 1 Apr 2003 15:17:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31K4OJM017121 for ; Tue, 1 Apr 2003 12:04:24 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31K4O8G017120 for ietf-calendar-bks; Tue, 1 Apr 2003 12:04:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31K4KJM017098 for ; Tue, 1 Apr 2003 12:04:21 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Tue, 01 Apr 2003 12:51:44 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 01 Apr 2003 13:03:20 -0700 From: "Preston Stephenson" To: Subject: Re: CAP & busytime? - CUA-BOT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 I'm confused. Doesn't the iTIP spec say that the response to the VFREEBUSY REQUEST is the VFREEBUSY REPLY with the FREEBUSY information? Is the following the way CAP is suppose to work then? CAP can't return the VFREEBUSY REPLY in response to the VFREEBUSY REQUEST. CAP can only return success or failure of the creation of the VFREEBUSY REQUEST. The CUA would need to use CAP to search for the VFREEBUSY REPLY using the UID returned from the VFREEBUSY REQUEST at a later time? Thanks. Preston Stephnson pstephenson@novell.com >>> Doug@royer.com 4/1/2003 12:34:53 PM >>> Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 03/31/2003 06:12:54 PM: > > > For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or > > > METHOD:REPLY for requesting and responding, respectively. In CAP, I > > > guess that would crudely map to a CREATE command with particular > TARGETs > > > but there is NOTHING to lead me to belive that the CS must do any > actual > > > processing beyond the actual request creation. > > > > In fact we squashed the CS from doing any work for the CUA. > > You need to have your CUA or a CUA-BOT do it for you. > > I dont recall that decision and I certainly think making VFREEBUSY data > totally disjoint from the contents of the associated calendar is a BAD > idea. It was under the 'roll-up' discussion. Only you and I thought it was a good idea. The WG smashed it. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET 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 Tue Apr 1 15:20:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13272 for ; Tue, 1 Apr 2003 15:20:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31K0CJM016431 for ; Tue, 1 Apr 2003 12:00:12 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31K0CWb016429 for ietf-calendar-bks; Tue, 1 Apr 2003 12:00:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31K0BJM016423 for ; Tue, 1 Apr 2003 12:00:11 -0800 (PST) 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 h31K09M4019998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Apr 2003 12:00:12 -0800 Message-ID: <3E89EFC3.5050602@Royer.com> Date: Tue, 01 Apr 2003 13:00:03 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070908050401010601060804" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070908050401010601060804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responsed on 03/31/2003 04:15:47 PM: > > > I may infer from the text under CREATE that I (or my CUA) must CREATE > > > the VFREEBUSY for it to exist (see create-vreply and create-comp). > > > > Yes. > > Umm, why should I (a CUA) be able to do that? Because this WG squashed it. > Having VFREEBUSY info > unrepresentable of the actual calendar data makes it useless for its > intended purpose. No. It means that CAP does not specify it. It does not mean that it can not be specified. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070908050401010601060804 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDEyMDAwMDNaMCMGCSqGSIb3DQEJBDEWBBQ6 0is+GGkU/SWlnJKIZgc3XLpLYTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAECHRxDFve++e CTtmkW9Wsx7rFuVqk7E++yG5izq4y5HKuJ9La9Hja05K7+88j4+vbazQX+dO23t4t62PBKfP OLtRcyn0/3rABbFodH/uisl32/8H32ZnsYJQpFtsoC6kcj1ft7NOOsPO5Xaw1abqk8A8YhBd HdUcp3lXsEcR+vyFYRX4cdFI/oMYh/juMz+m/6W/QkKNvU1iPdbnOOBuBbmpMRaAd7zZV5hm yKSM2YcbME8MMEWavS4Tb+TU80slhSo2zgASMxARX7NwzRBYF0iFbQYGNJcg9BtImo5HVzbF v503lBj5LRaf9k7+riYnrulr+Qp8dWeZNBJEPgYFvAAAAAAAAA== --------------ms070908050401010601060804-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 15:41:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14187 for ; Tue, 1 Apr 2003 15:41:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31KRJJM020578 for ; Tue, 1 Apr 2003 12:27:19 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31KRJNG020577 for ietf-calendar-bks; Tue, 1 Apr 2003 12:27:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h31KRGJM020571 for ; Tue, 1 Apr 2003 12:27:17 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040115295706086 for ; Tue, 01 Apr 2003 15:29:57 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Apr 2003 15:23:13 -0500 Message-ID: <3E89F530.6020207@centive.com> Date: Tue, 01 Apr 2003 15:23:12 -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: CAP & busytime? - CUA-BOT References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2003 20:23:13.0156 (UTC) FILETIME=[85139C40:01C2F88C] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Preston Stephenson wrote: >I'm confused. >Doesn't the iTIP spec say that the response to the VFREEBUSY REQUEST is >the VFREEBUSY REPLY with the FREEBUSY information? > >Is the following the way CAP is suppose to work then? > CAP can't return the VFREEBUSY REPLY in response to the VFREEBUSY >REQUEST. > CAP can only return success or failure of the creation of the >VFREEBUSY REQUEST. > The CUA would need to use CAP to search for the VFREEBUSY REPLY >using the UID returned from the VFREEBUSY REQUEST at a later time? > That does seem to be what Doug's saying--if CAP supports freebusy only as part of iTIP, then freebusy works the way iTIP works in CAP, which, I think, is CUA-to-CUA, with the CS used only as a message store. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 1 15:41:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14202 for ; Tue, 1 Apr 2003 15:41:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31KJiJM019596 for ; Tue, 1 Apr 2003 12:19:44 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31KJitk019595 for ietf-calendar-bks; Tue, 1 Apr 2003 12:19:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h31KJhJM019568 for ; Tue, 1 Apr 2003 12:19:43 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040115241108612 for ; Tue, 01 Apr 2003 15:24:11 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Apr 2003 15:17:28 -0500 Message-ID: <3E89F3D8.1050508@centive.com> Date: Tue, 01 Apr 2003 15:17:28 -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: CAP & busytime? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2003 20:17:28.0254 (UTC) FILETIME=[B77FBDE0:01C2F88B] 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: > And make each CUA consume even more cycles rebuilding VFREEBUSY data > and resending it. Hmm, lets weigh that against having the CS do it > automatically at a reduced cost in CUA load (thus better CUA > performance) and network bandwidth in addition to the CS resources > consumed to just deal with the added traffic. Note that this isn't necessarily conclusive--techniques for serving up relatively static data are well-known (think Web servers); it's usually cheaper than server-side processing. > Im sure that every 'thin' client author is very anxious to make sure > they also design their CUA so that it can _properly_ update the > VFREEBUSY info too... Then again maybe they will forgoe that and thin > client CUs will just have no busytime to return... Note that most people would probably say that someone using a thin client probably has a fat client on their desktop. Not a good answer, though; many people don't leave their desktops running all the time, so, if you accept an invitation with the thin client, your VFREEBUSY won't get updated until you next fire up your fat client. > As such the CUA wont have to sort thru all the VFREEBUSY data for my > entire calendar starting back in 1996 thru 2045 (dont ask!); You pre-expand repeating events, and cut them off after 50 years? > it should only be getting the data for the specified > DTSTART/DTEND/DURATION range. This section was predicated on "if there is only one". It sounds like the current plan is that the CS treats VFREEBUSY components as opaque, and just stores/delivers them for CUAs; in that case, the CS has to return the entirety of every VFREEBUSY that overlaps the requested range. If there's only one per CU, that means every VFREEBUSY request will return all the data. And the question arises: if there is more than one, how does it get updated properly? Suppose I have two CUAs; implementation A stores a separate VFREEBUSY for each week (starting on Sunday), and implementation B stores one for each month. My calendar now has duplicate VFREEBUSYs for the same periods, and we have the opportunity for them to get out of sync. For example, if A creates an event on 12 April 2003, and updates its VFREEBUSY, but B doesn't update its VFREEBUSY for all of April, then any request for a VFREEBUSY for 12 April will get two answers, one from the weekly component and one from the monthly. Which one is the requester supposed to believe? If, on the other hand, a CS is supposed to maintain freebusy data as data, and construct a VFREEBUSY from that data on request, then it's doing almost as much work as constructing a VFREEBUSY on request based on VEVENT data. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 1 16:02:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14995 for ; Tue, 1 Apr 2003 16:02:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31KjCJM021751 for ; Tue, 1 Apr 2003 12:45:12 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31KjC31021750 for ietf-calendar-bks; Tue, 1 Apr 2003 12:45:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31KjAJM021746 for ; Tue, 1 Apr 2003 12:45:10 -0800 (PST) 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 h31Kj9M4020573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Apr 2003 12:45:12 -0800 Message-ID: <3E89FA50.6090805@Royer.com> Date: Tue, 01 Apr 2003 13:45:04 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060008030109060101040302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060008030109060101040302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: > I'm confused. > Doesn't the iTIP spec say that the response to the VFREEBUSY REQUEST is > the VFREEBUSY REPLY with the FREEBUSY information? > > Is the following the way CAP is suppose to work then? > CAP can't return the VFREEBUSY REPLY in response to the VFREEBUSY > REQUEST. > CAP can only return success or failure of the creation of the > VFREEBUSY REQUEST. > The CUA would need to use CAP to search for the VFREEBUSY REPLY > using the UID returned from the VFREEBUSY REQUEST at a later time? CAP can save VFREEBUSY objects. CAP can fetch VFREEBUSY objects. How the objects themselves get populated is not part of the CUA <-> CS protocol - CAP. I agree it would be nice to automate the creation of VFREEBUSY objects in the CS. However this WG has not yet specified how this is done. It is not specified in the CUA <-> CS protocol - CAP. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060008030109060101040302 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDEyMDQ1MDRaMCMGCSqGSIb3DQEJBDEWBBQ7 4eZiE8UUyj8+f3IAe2F6mw38FDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAhQ5NquwsLs+b /ug+2X26Uqch4JFaAZaGdtKqcwrkwtVwcUvQjCrTHg1wS+4LfKVSLanB8raeGnxrKST/sy7d M+1F7eH4xtjRv8iUQA9mp2l5ETGbElNIWyKpjeHS3mm4rBdmxxXFtj7N581gGClVEgwQlWKu p73Asn1gpczNTaD0KbPX6rSPLW1VqH4gIqNW/sufYxL6WnB00gMGTYnxeAqqqh4Bpa6HfI0Q pQtHsFQ3+A8+DSz+344XTX+wXpAvKZfkq/0WoI5+J82gmgDuO/FN8RK5cb7LIZwTkVSv7CzT ZHI9QQ3X2SFyYjzf6TJ3ifedt1nGI1QfL14jAeOFAgAAAAAAAA== --------------ms060008030109060101040302-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 16:32:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16060 for ; Tue, 1 Apr 2003 16:32:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LKqJM022677 for ; Tue, 1 Apr 2003 13:20:54 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LKqVj022676 for ietf-calendar-bks; Tue, 1 Apr 2003 13:20:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31LKmJM022668 for ; Tue, 1 Apr 2003 13:20:50 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Tue, 01 Apr 2003 14:08:15 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 01 Apr 2003 14:20:04 -0700 From: "Preston Stephenson" To: Subject: Re: CAP & busytime? - CUA-BOT Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8FD035AF.78197640" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_8FD035AF.78197640 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In section 2.2 of the CAP spec. it says: "All scheduling operations (and) are as define(d) in [iTIP]. This memo makes no changes to any of the workflow described in [iTIP]." I implied by that I could do the iTIP functionality of returning the iTIP VFREEBUSY REPLY in the reply of the CAP create of the iTIP VFREEBUSY REQUEST. I have the problem that I can't store/save free/busy information. Separate question. I don't understand the first sentence. Should it be "All scheduling operations are as defined in [iTIP]."? Thanks. Preston Stephenson pstephenson@novell.com >>> Doug@royer.com 4/1/2003 1:45:04 PM >>> Preston Stephenson wrote: > I'm confused. > Doesn't the iTIP spec say that the response to the VFREEBUSY REQUEST is > the VFREEBUSY REPLY with the FREEBUSY information? > > Is the following the way CAP is suppose to work then? > CAP can't return the VFREEBUSY REPLY in response to the VFREEBUSY > REQUEST. > CAP can only return success or failure of the creation of the > VFREEBUSY REQUEST. > The CUA would need to use CAP to search for the VFREEBUSY REPLY > using the UID returned from the VFREEBUSY REQUEST at a later time? CAP can save VFREEBUSY objects. CAP can fetch VFREEBUSY objects. How the objects themselves get populated is not part of the CUA <-> CS protocol - CAP. I agree it would be nice to automate the creation of VFREEBUSY objects in the CS. However this WG has not yet specified how this is done. It is not specified in the CUA <-> CS protocol - CAP. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_8FD035AF.78197640 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit
In section 2.2 of the CAP spec. it says: "All scheduling operations (and) are as define(d) in [iTIP]. This memo makes no changes to any of the workflow described in [iTIP]." I implied by that I could do the iTIP functionality of returning the iTIP VFREEBUSY REPLY in the reply of the CAP create of the iTIP VFREEBUSY REQUEST. I have the problem that I can't store/save free/busy information.
 
Separate question. I don't understand the first sentence. Should it be "All scheduling operations are as defined in [iTIP]."?
Thanks.
 
Preston Stephenson

>>> Doug@royer.com 4/1/2003 1:45:04 PM >>>


Preston Stephenson wrote:
> I'm confused.
> Doesn't the iTIP spec say that the response to the VFREEBUSY REQUEST is
> the VFREEBUSY REPLY with the FREEBUSY information?
>
> Is the following the way CAP is suppose to work then?
>    CAP can't return the VFREEBUSY REPLY in response to the VFREEBUSY
> REQUEST.
>    CAP can only return success or failure of the creation of the
> VFREEBUSY REQUEST.
>    The CUA would need to use CAP to search for the VFREEBUSY REPLY
> using the UID returned from the VFREEBUSY REQUEST at a later time?

CAP can save VFREEBUSY objects.
CAP can fetch VFREEBUSY objects.

How the objects themselves get populated is not part of
the CUA <-> CS protocol - CAP.

I agree it would be nice to automate the creation of
VFREEBUSY objects in the CS. However this WG  has not
yet specified how this is done. It is not specified in
the CUA <-> CS protocol - CAP.




--

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

                 We Do Standards - You Need Standards
--=_8FD035AF.78197640-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 17:07:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17868 for ; Tue, 1 Apr 2003 17:07:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LwmJM023622 for ; Tue, 1 Apr 2003 13:58:48 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LwlmV023621 for ietf-calendar-bks; Tue, 1 Apr 2003 13:58:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LwkJM023615 for ; Tue, 1 Apr 2003 13:58:47 -0800 (PST) Received: (qmail 27085 invoked from network); 1 Apr 2003 21:58:44 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 1 Apr 2003 21:58:44 -0000 Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT From: Dan Winship To: ietf-calendar@imc.org In-Reply-To: <3E89EF4E.6080503@Royer.com> References: <3E89EF4E.6080503@Royer.com> Content-Type: text/plain Message-Id: <1049234298.4266.223.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 01 Apr 2003 16:58:18 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 2003-04-01 at 14:58, Doug Royer wrote: > Bruce_Kahn@notesdev.ibm.com wrote: > > > > The only reasonble source for keeping the VFREEBUSY accurate is to have > > it done by the CS as changes are made to the calendar. _Assuming_ that > > an unspecified "Bot" mechanism is the way that it should/would/MAY be > > done is NOT sufficient here if we want that key functionality in CAP. > > CAP 1.0 needs to provide that basic functionality in it or we severly > > risk loosing user adoption. > > Need told me and Pat repeated that we can not add features to CAP > unless 20 people on this list insist tht it must be done. Well, I agree with Bruce, so there's 2... -- Dan From owner-ietf-calendar@mail.imc.org Tue Apr 1 17:34:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18666 for ; Tue, 1 Apr 2003 17:34:21 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MDuJM024187 for ; Tue, 1 Apr 2003 14:13:58 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31MDu2v024186 for ietf-calendar-bks; Tue, 1 Apr 2003 14:13:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h31MDsJM024178 for ; Tue, 1 Apr 2003 14:13:55 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040117182314833 for ; Tue, 01 Apr 2003 17:18:23 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Apr 2003 17:11:39 -0500 Message-ID: <3E8A0E9B.3050706@centive.com> Date: Tue, 01 Apr 2003 17:11: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: calsch Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT References: <3E89EF4E.6080503@Royer.com> <1049234298.4266.223.camel@twelve-monkeys.boston.ximian.com> In-Reply-To: <1049234298.4266.223.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2003 22:11:39.0692 (UTC) FILETIME=[AB4636C0:01C2F89B] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan Winship wrote: >On Tue, 2003-04-01 at 14:58, Doug Royer wrote: > > >>Need told me and Pat repeated that we can not add features to CAP >>unless 20 people on this list insist tht it must be done. >> >> > >Well, I agree with Bruce, so there's 2... > > 3. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 1 17:56:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19154 for ; Tue, 1 Apr 2003 17:56:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31MfIJM025974 for ; Tue, 1 Apr 2003 14:41:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31MfIH7025973 for ietf-calendar-bks; Tue, 1 Apr 2003 14:41:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31MfHJM025964 for ; Tue, 1 Apr 2003 14:41:17 -0800 (PST) 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 h31MfGM4021505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Apr 2003 14:41:19 -0800 Message-ID: <3E8A1582.3000505@Royer.com> Date: Tue, 01 Apr 2003 15:41:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060107070003000307030608" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060107070003000307030608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: > In section 2.2 of the CAP spec. it says: "All scheduling operations > (and) are as define(d) in [iTIP]. This memo makes no changes to any of > the workflow described in [iTIP]." I implied by that I could do the iTIP > functionality of returning the iTIP VFREEBUSY REPLY in the reply of the > CAP create of the iTIP VFREEBUSY REQUEST. I have the problem that I > can't store/save free/busy information. You can store all iTIP messages in a CS. Including VFREEBUSY. They have methods so they are stored in the UNPROCESSED state waiting like all other UNPROCESSED iTIP messages for a CUA to act on them. With a CUA-BOT, then you can have it automatically respond to METHOD:REQUEST for VFREEBUSY and other iTIP messages. > Separate question. I don't understand the first sentence. Should it be > "All scheduling operations are as defined in [iTIP]."? > Thanks. Yes - thanks. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060107070003000307030608 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDEyMjQxMDZaMCMGCSqGSIb3DQEJBDEWBBS5 ciqLpOcFgLhAUKMnVsX0rC8aETBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAQtvByP0TjOtQ GErhTHVeG8CdC5qAP7/G+tkJpEG2E76/BSl7xFYUora4qyyJphvinRTHIZxsiqqymWC0uZbL LyFA4Xs5pqpImq9atknguXc6N/u8Gv6vQUmq2wJEuAJWNZXASmvnkAwVStDF79trDq+BPPFs qsvi4yOwqLFr4hXQhdG+oW/h6Ql7N5CxRkmWI2vp7EDcBjQmEFgN5LOsQWAaWyVRumn2m+tU DxjyNHXETv6y5IwvpbantU4mW4JCYNo0YtyPP+Pt4rRITVW1ohEfu68dzKMP5XfRD4Tniqoo otdQqibw8LF0apmahdXNb2U3i9MlbjE0iwUk1hIT7AAAAAAAAA== --------------ms060107070003000307030608-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 18:15:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20966 for ; Tue, 1 Apr 2003 18:15:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31N4XJM027182 for ; Tue, 1 Apr 2003 15:04:33 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31N4X90027181 for ietf-calendar-bks; Tue, 1 Apr 2003 15:04:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h31N4VJM027174 for ; Tue, 1 Apr 2003 15:04:31 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Tue, 01 Apr 2003 15:51:54 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 01 Apr 2003 16:03:50 -0700 From: "Preston Stephenson" To: Subject: Re: CAP & busytime? - CUA-BOT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Sorry, I didn't speak clearly before. I'm saying that as a [my] CS, I don't have the capability to store VFREEBUSY information. If a CUA tries to create a VFREEBUSY object on my CS, The CS will have to reply that the capability is not supported. I on the other hand as a CS, I can generate and return VFREEBUSY information upon request. I'm trying to map the CAP / iMIP / iTIP functionality onto an existing product. I don't want to write a new program that just supports CAP. It would be easier to provide the iTIP functionality through CAP without having to re-architect my existing application. Preston Stephenson pstephenson@novell.com >>> Doug@royer.com 4/1/2003 3:41:06 PM >>> Preston Stephenson wrote: > In section 2.2 of the CAP spec. it says: "All scheduling operations > (and) are as define(d) in [iTIP]. This memo makes no changes to any of > the workflow described in [iTIP]." I implied by that I could do the iTIP > functionality of returning the iTIP VFREEBUSY REPLY in the reply of the > CAP create of the iTIP VFREEBUSY REQUEST. I have the problem that I > can't store/save free/busy information. You can store all iTIP messages in a CS. Including VFREEBUSY. They have methods so they are stored in the UNPROCESSED state waiting like all other UNPROCESSED iTIP messages for a CUA to act on them. With a CUA-BOT, then you can have it automatically respond to METHOD:REQUEST for VFREEBUSY and other iTIP messages. > Separate question. I don't understand the first sentence. Should it be > "All scheduling operations are as defined in [iTIP]."? > Thanks. Yes - thanks. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET 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 Tue Apr 1 18:18:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21153 for ; Tue, 1 Apr 2003 18:18:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31N42JM027159 for ; Tue, 1 Apr 2003 15:04:02 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31N42Ux027158 for ietf-calendar-bks; Tue, 1 Apr 2003 15:04:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31N40JM027154 for ; Tue, 1 Apr 2003 15:04:01 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h31N438J003912 for ; Tue, 1 Apr 2003 18:04:03 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h31N42tQ004033 for ; Tue, 1 Apr 2003 18:04:03 -0500 (EST) Received: from monalisa (MONA-LISA.MIT.EDU [18.18.1.114]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with SMTP id h31N42U8016992 for ; Tue, 1 Apr 2003 18:04:02 -0500 (EST) From: "Paul B. Hill" To: Subject: RE: CAP & busytime? - not CAP reqirement - CUA-BOT Date: Tue, 1 Apr 2003 18:04:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1049234298.4266.223.camel@twelve-monkeys.boston.ximian.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, we're up to 4. Keep those "votes" coming :) -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Dan Winship Sent: Tuesday, April 01, 2003 4:58 PM To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT On Tue, 2003-04-01 at 14:58, Doug Royer wrote: > Bruce_Kahn@notesdev.ibm.com wrote: > > > > The only reasonble source for keeping the VFREEBUSY accurate is to have > > it done by the CS as changes are made to the calendar. _Assuming_ that > > an unspecified "Bot" mechanism is the way that it should/would/MAY be > > done is NOT sufficient here if we want that key functionality in CAP. > > CAP 1.0 needs to provide that basic functionality in it or we severly > > risk loosing user adoption. > > Need told me and Pat repeated that we can not add features to CAP > unless 20 people on this list insist tht it must be done. Well, I agree with Bruce, so there's 2... -- Dan From owner-ietf-calendar@mail.imc.org Tue Apr 1 19:51:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23537 for ; Tue, 1 Apr 2003 19:51:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h320dOJM002868 for ; Tue, 1 Apr 2003 16:39:24 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h320dNFX002867 for ietf-calendar-bks; Tue, 1 Apr 2003 16:39:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h320dMJM002863 for ; Tue, 1 Apr 2003 16:39:22 -0800 (PST) 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 h320dLM4022355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Apr 2003 16:39:24 -0800 Message-ID: <3E8A312F.4030801@Royer.com> Date: Tue, 01 Apr 2003 17:39:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000004070603080706000206" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000004070603080706000206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: > Sorry, I didn't speak clearly before. ... (see below...) I think you are saying that your VCAR (decreed or not) does not allow VFREEBUSY to be stored in your CS. That is fine. I also think that you are saying that your CS will magically somehow provide a valid VFREEBUSY to requesting CUA's. That is is also fine. However CAP does not mandate or specify how that is done. In effect you have a mini-CUA (BOT) built into your CS that deposits (from the CUA's point of view) VFREEBUSY components into each calendar (when in reality you probably generate them dynamically and on the fly). I do not see that you are breaking CAP. Another approach is for a CS to not generate them AND not allow CUA to deposit them at which point the CS would NOT supply VFREEBUSY in its COMPONENTS CAPABILITY reply and a CUA would know to never ask that CS. Another approach is for the CS to allow a CUA to deposit and fetch VFREEBUSY components just like any other iTIP components, and then some CUA (BOT?) must then manage the VFREEBUSY on the CS. One of the reasons that we dropped automatically processing VFREEBUSY processing on the CS was there is going to be a LARGE debate on how its contents are going to be generated. Must I include all OPAQUE object times? What if I do not want to? Why can I not write a custom CS that is for my business that takes into account company hours and holidays. Would I have to make entries in my company calendar that block out closed times? What if I want the results of a VFREEBUSY request to be dynamic so that my BOSS get to schedule in my 'do no bother me time' but non-BOSS CU's see it at blocked. Would I have to generate components in my calendar for the time I am normally sleeping? If not what is to keep that from being considered free time? I schedule with people around the world. Must the BUSY time match the booked objects in the calendar? Can I set aside time for travel? As in I want 15 minutes before and after all meetings at LOCATION:x automatically. Why can't I allow each user to specify how their VFREEBUSY time is generated? What happens when a user goes on vacation? If some of the appointments are already OPAQUE/NOCONFLICT in the calendar when they go on vacation, they can not enter any 1-week entries in their calendar so they have to create a series of entries that work around the booked NOCONFLICT time. Why can't I just have my CUA deposit a VFREEBUSY that shows the vacation time as busy? Can I turn on/off the CS's ability to automatically generate VFREEBUSY times. I think it is best left to a separate draft. Preston Stephenson wrote: > Sorry, I didn't speak clearly before. > I'm saying that as a [my] CS, I don't have the capability to store > VFREEBUSY information. > If a CUA tries to create a VFREEBUSY object on my CS, The CS will have > to reply that the capability is not supported. > I on the other hand as a CS, I can generate and return VFREEBUSY > information upon request. > > I'm trying to map the CAP / iMIP / iTIP functionality onto an existing > product. > I don't want to write a new program that just supports CAP. > It would be easier to provide the iTIP functionality through CAP > without having to re-architect my existing application. > > Preston Stephenson > pstephenson@novell.com -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000004070603080706000206 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIwMDM5MTFaMCMGCSqGSIb3DQEJBDEWBBQn 2gxEmrXn0PYSXl68588Wb8BaFTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAlOfwbz6SvyxY k6hpY3le/UTI7nVwK6fxVW4ZHiR2KL8yCwJXX8feAUjllF5b9oNmgFlC50sscO8E1i8obKIl rTjo582qj/fM0PaBi6vIYzQM7sSWQBOohA2RKzk9aWwA0ieDJdetTrz0ZzY9NAKjX1TrvwIT /9jWrBf2YF4kRP3i95VUoIJHP71yG7VbTCbZLTSk9zO4oR3NHFiPreDyeSakG9a5rHQiT4De fjWeJjbmvqdauE3+YpWuIPXFSp99xKCEDH82yyxrLfSvyoonWkPx17vM1Z3ljAa5wg1+OP6N otNEzrZXL4G6i8qc7Wr6TCuKSwoq472bnXHeev773QAAAAAAAA== --------------ms000004070603080706000206-- From owner-ietf-calendar@mail.imc.org Tue Apr 1 21:30:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25759 for ; Tue, 1 Apr 2003 21:30:32 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322F7JM007021 for ; Tue, 1 Apr 2003 18:15:07 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h322F7e9007020 for ietf-calendar-bks; Tue, 1 Apr 2003 18:15:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h322F6JM007016 for ; Tue, 1 Apr 2003 18:15:06 -0800 (PST) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h322IRf06434; Tue, 1 Apr 2003 18:18:27 -0800 (PST) Date: Tue, 1 Apr 2003 18:18:27 -0800 (PST) From: slh@bikini.cac.washington.edu Message-Id: <200304020218.h322IRf06434@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: cap-10 section 7. comments Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: the numbers in [] at the beginning of each are the page and line numbers. I think the markup is obvious, but: X under text indicates it should be deleted ^ under text indicates an insertion point (insert before) followed by the new text - under text indicates it should be changed (w/a specific substitution) followed by the new text or a comment/question * under text indicates what is specifically being commented on followed by a comment in [] ---------------------------------------- [55;3070] Conformance: This property can be specified in the "TRIGGER" --------parameter properties. ---y ---------------------------------------- [56;3086] A CUA may add the "ENABLE" parameter to any "TRIGGER" property before booking the component. If the "ENABLE" parameter is set to "FALSE", then the alarm will be ignored by the CUA. If set to "TRUE", or if the "ENABLE" property is not in the "TRIGGER" property, the alarm is --------parameter enabled. The CUA should remove the "ENABLE" parameter before forwarding the component to a non-CAP CUA. Formal Definition: The property is defined by the following notation: --------parameter enable-param = "ENABLE" "=" boolean ******************** [ in most of the other parameter definitions, the ";" is included in the parameter definition (instead of the property definition). this is one of the exceptions. ] Example: The following is an example of this property for a "VAGENDA" component: ********************************************************************* [ rewrite: Example: The following is an example of this parameter for a "TRIGGER" property: ] TRIGGER;ENABLE=FALSE;RELATED=END:PT5M ---------------------------------------- [56;3111] Purpose: When used in a "CMD" component provides a unique identifier. ---------property ************************************************************ [ sentences like this do not seem to read qutie right; like a comma or word is missing. ] ---------------------------------------- [56;3124] Formal Definition: The property is defined by the following notation: --------parameter ---------------------------------------- [57;3147] unique-id = ; text ****** [ should text not be a comment? and in general should there be abnf w/o something on the rhs? ] Example: The following is an example of this parameter component: XXXXXXXXXX ---------------------------------------- [57;3167] Conformance: This property can be specified in the "CMD" property. --------parameter When present in a "CMD" property the "LATENCY" parameter specifies the time in sections when the command timeout expires. --------seconds ---------------------------------------- [58;3217] A CUA may add the "LOCAL" parameter to the "SEQUENCE" property before booking the component. If the "LOCAL" parameter is set to "FALSE", ******* then the alarm MUST NOT be forwarded to any other calender. If set to "TRUE", or of the "LOCAL" property is not in the "SEQUENCE" ****** --if --------parameter [ has true and false been inverted here? ] property, the alarm is global. The CUA should remove the "LOCAL" parameter before forwarding the component to a non-cap CUA other ****---CAP XXXXXX calendars. XXXXXXXXX [ in general, ``non'' seems to be inconsistently followed by ``-'' or `` '', but maybe the rules of punctuation specify this? ] Formal Definition: The property is defined by the following notation: --------parameter local-param = "LOCAL" "=" boolean ******************* [ another exception to the ";" being w/the param definition. ] ---------------------------------------- [59;3260] A CUA may add the "LOCAL" parameter to the "LOCALIZE" parameter to XXXXXXXXXXXXXXXXXXXXXXXXX the "CMD" property to specify the language of any error or warning messages. Formal Definition: The property is defined by the following notation: --------parameter localize-param = ";" "LOCALIZE" "=" beep-localize ; The value supplied MUST BE one value from the initial ; [BEEP] greeting 'localize' attribute specifying ; the locale to use for error messages during ; this instance of the command sent. beep-localize = ; text ****** [ should text not be a comment? ] ---------------------------------------- [59;3292] Conformance: This parameter can be specified in the "CMD" properties. ---y A CUA adds the "OPTIONS" parameter to the "LOCALIZE" parameter to the XXXXXXXXXXXXXXXXXXXXXXXXXXXX "CMD" property when the command needs extra values. Formal Definition: The property is defined by the following notation: --------parameter ---------------------------------------- From owner-ietf-calendar@mail.imc.org Wed Apr 2 08:22:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08410 for ; Wed, 2 Apr 2003 08:22:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32D7fJM001136 for ; Wed, 2 Apr 2003 05:07:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32D7fYt001135 for ietf-calendar-bks; Wed, 2 Apr 2003 05:07:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32D7dJM001102 for ; Wed, 2 Apr 2003 05:07:39 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Wed, 02 Apr 2003 05:54:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 02 Apr 2003 06:06:44 -0700 From: "Preston Stephenson" To: "<" Subject: RE: CAP & busytime? - not CAP reqirement - CUA-BOT Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_B2ED0BB3.A0C1AE9F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_B2ED0BB3.A0C1AE9F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 5 Preston >>> "Paul B. Hill" 4/1/2003 4:04:02 PM >>> OK, we're up to 4. Keep those "votes" coming :) -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Dan Winship Sent: Tuesday, April 01, 2003 4:58 PM To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT On Tue, 2003-04-01 at 14:58, Doug Royer wrote: > Bruce_Kahn@notesdev.ibm.com wrote: > > > > The only reasonble source for keeping the VFREEBUSY accurate is to have > > it done by the CS as changes are made to the calendar. _Assuming_ that > > an unspecified "Bot" mechanism is the way that it should/would/MAY be > > done is NOT sufficient here if we want that key functionality in CAP. > > CAP 1.0 needs to provide that basic functionality in it or we severly > > risk loosing user adoption. > > Need told me and Pat repeated that we can not add features to CAP > unless 20 people on this list insist tht it must be done. Well, I agree with Bruce, so there's 2... -- Dan --=_B2ED0BB3.A0C1AE9F Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit
5
Preston

>>> "Paul B. Hill" <pbh@MIT.EDU> 4/1/2003 4:04:02 PM >>>

OK, we're up to 4. Keep those "votes" coming :)

-----Original Message-----
From: owner-ietf-calendar@mail.imc.org
[mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Dan Winship
Sent: Tuesday, April 01, 2003 4:58 PM
To: ietf-calendar@imc.org
Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT



On Tue, 2003-04-01 at 14:58, Doug Royer wrote:
> Bruce_Kahn@notesdev.ibm.com wrote:
>
>
> > The only reasonble source for keeping the VFREEBUSY accurate is to have
> > it done by the CS as changes are made to the calendar.  _Assuming_ that
> > an unspecified "Bot" mechanism  is the way that it should/would/MAY be
> > done is NOT sufficient here if we want that key functionality in CAP.
> >  CAP 1.0 needs to provide that basic functionality in it or we severly
> > risk loosing user adoption.
>
> Need told me and Pat repeated that we can not add features to CAP
> unless 20 people on this list insist tht it must be done.

Well, I agree with Bruce, so there's 2...

-- Dan


--=_B2ED0BB3.A0C1AE9F-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 08:36:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08939 for ; Wed, 2 Apr 2003 08:36:21 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32DMZJM002127 for ; Wed, 2 Apr 2003 05:22:35 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32DMZvu002126 for ietf-calendar-bks; Wed, 2 Apr 2003 05:22:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32DMXJM002113 for ; Wed, 2 Apr 2003 05:22:34 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Wed, 02 Apr 2003 06:09:57 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 02 Apr 2003 06:21:43 -0700 From: "Preston Stephenson" To: Subject: Re: CAP & busytime? - CUA-BOT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Thank you for taking your time to respond and you patience. I understand there are different ways to architect the functionality. I just need further clarification. The CAP specification states that it supports the iTIP functionality. Does that mean? 1) CAP specifies that the iTIP functionaly is performed by the CUA. 2) The CS is just that, a store. 3) The CS does not perform any of the iTIP functionality. Thanks. Preston >>> Doug@royer.com 4/1/2003 5:39:11 PM >>> Preston Stephenson wrote: > Sorry, I didn't speak clearly before. ... (see below...) I think you are saying that your VCAR (decreed or not) does not allow VFREEBUSY to be stored in your CS. That is fine. I also think that you are saying that your CS will magically somehow provide a valid VFREEBUSY to requesting CUA's. That is is also fine. However CAP does not mandate or specify how that is done. In effect you have a mini-CUA (BOT) built into your CS that deposits (from the CUA's point of view) VFREEBUSY components into each calendar (when in reality you probably generate them dynamically and on the fly). I do not see that you are breaking CAP. Another approach is for a CS to not generate them AND not allow CUA to deposit them at which point the CS would NOT supply VFREEBUSY in its COMPONENTS CAPABILITY reply and a CUA would know to never ask that CS. Another approach is for the CS to allow a CUA to deposit and fetch VFREEBUSY components just like any other iTIP components, and then some CUA (BOT?) must then manage the VFREEBUSY on the CS. One of the reasons that we dropped automatically processing VFREEBUSY processing on the CS was there is going to be a LARGE debate on how its contents are going to be generated. Must I include all OPAQUE object times? What if I do not want to? Why can I not write a custom CS that is for my business that takes into account company hours and holidays. Would I have to make entries in my company calendar that block out closed times? What if I want the results of a VFREEBUSY request to be dynamic so that my BOSS get to schedule in my 'do no bother me time' but non-BOSS CU's see it at blocked. Would I have to generate components in my calendar for the time I am normally sleeping? If not what is to keep that from being considered free time? I schedule with people around the world. Must the BUSY time match the booked objects in the calendar? Can I set aside time for travel? As in I want 15 minutes before and after all meetings at LOCATION:x automatically. Why can't I allow each user to specify how their VFREEBUSY time is generated? What happens when a user goes on vacation? If some of the appointments are already OPAQUE/NOCONFLICT in the calendar when they go on vacation, they can not enter any 1-week entries in their calendar so they have to create a series of entries that work around the booked NOCONFLICT time. Why can't I just have my CUA deposit a VFREEBUSY that shows the vacation time as busy? Can I turn on/off the CS's ability to automatically generate VFREEBUSY times. I think it is best left to a separate draft. Preston Stephenson wrote: > Sorry, I didn't speak clearly before. > I'm saying that as a [my] CS, I don't have the capability to store > VFREEBUSY information. > If a CUA tries to create a VFREEBUSY object on my CS, The CS will have > to reply that the capability is not supported. > I on the other hand as a CS, I can generate and return VFREEBUSY > information upon request. > > I'm trying to map the CAP / iMIP / iTIP functionality onto an existing > product. > I don't want to write a new program that just supports CAP. > It would be easier to provide the iTIP functionality through CAP > without having to re-architect my existing application. > > Preston Stephenson > pstephenson@novell.com -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET 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 Wed Apr 2 09:39:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10643 for ; Wed, 2 Apr 2003 09:39:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32ELLJM005463 for ; Wed, 2 Apr 2003 06:21:21 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32ELLrg005462 for ietf-calendar-bks; Wed, 2 Apr 2003 06:21:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32ELJJM005458 for ; Wed, 2 Apr 2003 06:21:20 -0800 (PST) In-Reply-To: <3E89E9DD.8030306@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 09:21:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 09:21:05 AM, Serialize complete at 04/02/2003 09:21:05 AM Content-Type: multipart/alternative; boundary="=_alternative 004E900B85256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004E900B85256CFC_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 04/01/2003 02:34:53 PM: > > I dont recall that decision and I certainly think making VFREEBUSY data > > totally disjoint from the contents of the associated calendar is a BAD > > idea. > > It was under the 'roll-up' discussion. Only you and I thought it > was a good idea. The WG smashed it. Hmm, Im unable to find 'roll-up' in the busytime context in my archives. I do see that we had some discussions (and agreement) on NOT doing calendar _content_ roll-up but I see nothing in the context of automatic busytime 'roll-up'. The phrase 'roll-up' appears in 3 threads (excluding this current thread): 1: "(long) problems with CAP not having "users" and hierarchical calendars " started 04/09/99 04:46:03 PM AST by Paul Hill 2: "Rollup of calendar content" started 05/19/99 02:23:53 PM GMT by Frank Dawson 3: "Proposed removal of hierarchy from CAP" started pre-12/28/2001 02:05:05 PM MST and discussed by Doug Royer, Steve Mansour and Shannon Clark The first two threads discuss the issues inherent in calendar content rollup and were basically agreed on by all that for CAP 1.0 we do NOT have calendar content roll-up (or rollup). This is still a good thing. (Doug: Do you still have that separate roll-up draft on hold?) The last thread was really discussing the issues around relationships and content rollup and is not related to any busytime discussions. There was some discussion of the impact on content rollup when doing busytime queries in the 1st thread (and Doug only briefly mentioned it 1 time in the 2nd thread) but the gist of the references were that content roll-up would make doing busytime searching inaccurate (ie: The actual VEVENT could be in a 'child calendar' and thus not findable when TARGETing a parent calendar for finding it) or unreliable (ie: "The FREEBUSY says Im busy from 1PM-1:30PM today but there is NOTHING on my calendar for that time. What gives?"). I can find no "We shall not make dynamic/automatic busytime maintenance a CAP 1.0 feature" decision in the archives. From what Ive heard so far from others is that having the CS do the lifting here rather than make all CUAs do it is the right thing to do, its just that Doug thinks this was already covered and considered Closed. That sound accurate? 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 004E900B85256CFC_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 04/01/2003 02:34:53 PM:
> > I dont recall that decision and I certainly think making VFREEBUSY data
> > totally disjoint from the contents of the associated calendar is a BAD
> > idea.
>
> It was under the 'roll-up' discussion. Only you and I thought it
> was a good idea. The WG smashed it.
Hmm, Im unable to find 'roll-up' in the busytime context in my archives.  I do see that we had some discussions (and agreement) on NOT doing calendar _content_ roll-up but I see nothing in the context of automatic busytime 'roll-up'.

The phrase 'roll-up' appears in 3 threads (excluding this current thread):

1: "(long) problems with CAP not having "users" and hierarchical calendars" started 04/09/99 04:46:03 PM AST by Paul Hill
2: "Rollup of calendar content" started 05/19/99 02:23:53 PM GMT by Frank Dawson
3: "Proposed removal of hierarchy from CAP" started pre-12/28/2001 02:05:05 PM MST and discussed by Doug Royer, Steve Mansour and Shannon Clark

The first two threads discuss the issues inherent in calendar content rollup and were basically agreed on by all that for CAP 1.0 we do NOT have calendar content roll-up (or rollup).  This is still a good thing.  (Doug: Do you still have that separate roll-up draft on hold?)

The last thread was really discussing the issues around relationships and content rollup and is not related to any busytime discussions.

There was some discussion of the impact on content rollup when doing busytime queries in the 1st thread (and Doug only briefly mentioned it 1 time in the 2nd thread) but the gist of the references were that content roll-up would make doing busytime searching inaccurate (ie: The actual VEVENT could be in a 'child calendar' and thus not findable when TARGETing a parent calendar for finding it) or unreliable (ie: "The FREEBUSY says Im busy from 1PM-1:30PM today but there is NOTHING on my calendar for that time.  What gives?").

I can find no "We shall not make dynamic/automatic busytime maintenance a CAP 1.0 feature" decision in the archives.  From what Ive heard so far from others is that having the CS do the lifting here rather than make all CUAs do it is the right thing to do, its just that Doug thinks this was already covered and considered Closed.  That sound accurate?

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 004E900B85256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 09:56:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11250 for ; Wed, 2 Apr 2003 09:56:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EcaJM005960 for ; Wed, 2 Apr 2003 06:38:36 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32EcaYQ005959 for ietf-calendar-bks; Wed, 2 Apr 2003 06:38:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EcXJM005953 for ; Wed, 2 Apr 2003 06:38:34 -0800 (PST) Received: (qmail 8382 invoked from network); 2 Apr 2003 14:38:28 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 2 Apr 2003 14:38:28 -0000 Subject: cap-10 sections 1-5 comments/questions (mostly boring) From: Dan Winship To: ietf-calendar@imc.org Content-Type: text/plain Message-Id: <1049294291.4766.44.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 02 Apr 2003 09:38:11 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Trying not to duplicate too much the comments made by the last critiquer... > 1. Introduction > the CUA is responsible for correctly generating iCalendar objects to > non CAP processes. Not grammatical. s/to/for/ ? > The definition of new components, properties, parameter's, and value > types are broken into two parts. The first part summarizes and > defined the new objects. The second part provides the detail and any > ABNF for those objects. s/'// s/are/is/ s/defined/defines/ s/any// ? [Whoever wrote most of the text likes the word "any" a lot] > 1.1 Formatting Conventions A forward reference to 1.2 and 1.3 would help a lot here The odd use of "quoted-string" instead of "quoted string" matches the other calendaring RFCs, so I guess it's not considered a bug? Likewise the random selection between the words "capitalized", "uppercase", "upper-case", and "upper case" in different paragraphs? > Enumerated values defined by this memo are referred to with > capitalized text, either alone or followed by the word "value". Should be "capitalized, quoted strings of text" like everything else. > Calendar components defined by [iCAL] ... should start a new paragraph. Also, it shouldn't say "defined by [iCAL]" since the convention is used for calendar components defined by CAP as well. Likewise, "Properties defined by this memo" and "Property parameters defined by this memo" shouldn't say "defined by this memo". > 1.3 Definitions These need to be re-alphabetized before last call. > BOOKED - ... This isn't a definition of BOOKED, it's a definition of object states. It's also completely incomprehensible. The stuff in section 2.2 is more salvageable, so this definition should probably just go away / be merged there. > Calendar - A collection of logically related objects or entities > each of which may be associated with a calendar date and possibly > time of day. These entities can include calendar properties or > components. In addition, a calendar might be related to other > calendars with the "RELATED-TO" property. A calendar is > identified by its unique calendar identifier. The [iCAL] defines > the initial calendar properties, calendar components and > properties that make up the contents of a calendar. For such a large definition, this doesn't say much. The first two sentences are incredibly vague. (Is my inbox a Calendar?). The "RELATED-TO" sentence feels arbitrarily tacked-on. How about: Calendar - A collection of iCalendar components and properties associated with a particular CU, encapsulated in a "VAGENDA" component. > Calendar Address - Also See Calendar URL - they are one in the same > for CAP addresses. The calendar address can also be the value to > the "ATTENDEE" and "ORGANIZER" properties as defined in [iCAL]. Likewise with the vagueness. > Calendar Policy - A CAP operational restriction on the access or > manipulation of a calendar. These may be outside of the scope of > the CAP protocol. An example of an implementation or site policy > is, "events MUST BE scheduled in unit intervals of one hour". s/MUST BE/must be/, since this is not an RFC 2119 MUST. (There are lots of other places where "MUST BE" should probably be "MUST be".) If the example policy above is not considered pathological behavior on the part of the CS, then there really ought to be a REQUEST-STATUS meaning "command failed because it violates policy" (and/or "command succeeded after mangling parameters to suit policy") so the CUA and CU have some hint about what's going on. > Calendar Store (CS) - The data and service model definition for a > Calendar Store as defined in this memo. Kinda circular... > Calendar Server - An implementation of a Calendar Store (CS) that > manages one or more calendars. Which is different from a Calendar Store how? "Calendar Server" doesn't get used anywhere else in the spec anyway. How about something like: Calendar Store (CS) - A server that a CUA connects to to query and manipulate calendars. Also called a Calendar Server. > Calendar Store Identifier (CSID) - The globally unique identifier > for an individual CS. A CSID consists of the host and port > portions of a "Common Internet Scheme Syntax" part of a URL, as > defined by [URL]. The CAP spec mixes and matches references to [URL] and [URI]. The older [URL] references need to be updated to point to [URI] instead. > Calendar Store Components - Components maintained in a CS specify a > grouping of calendar store-wide information. Should be "Components maintained in a CS THAT specify"? > Calendar Store Properties - Properties maintained in a Calendar > Store calendar store-wide information. Likewise "that specify calendar-store-wide information"? > Delegate > Designate Neither of these definitions are used elsewhere in the document. > Overlapped Booking Likewise, this definition isn't referred to elsewhere, and the text would probably be more understandable if it was moved to 8.37 ("TRANSP Property") > 2. Additions to iCalendar The organization here seems arbitrary. (Why is "New Value Types" (2.1) a parent to "New Parameters" (2.1.1)?). > A CU may wish to set their own alarm (local alarms) on components. > These local alarms are not to be forwarded to other CUs, CUAs, or CSs > as are the "SEQUENCE" property and the "ENABLE" parameter. I think that is supposed to mean that SEQUENCE and ENABLE should *not* be forwarded, but I don't think it actually succeeds in meaning that. The semantic discussion should probably just be xreffed from here anyway. > 2.1 New Value Types (summary) should have hyphens between the names and definitions for consistency with everything else > CALQUERY The "CAL-QUERY" value type is ... s/CALQUERY/CAL-QUERY/ > ID - The "ID" parameter specifies a unique identifier to be used for > any outstanding commands. That makes it sound like you specify it once and it keeps applying to new commands later. "to be used to identify responses to a command". > LOCAL - The "LOCAL" parameter in CAP is used to tag a "SEQUENCE" > property in a "VALARM" component to signify that a VALARM is local > or to be distributed. (Section 7.5). "to signify whether or not a VALARM is to be distributed" > SEQUENCE - When the "SEQUENCE" parameter is used in a "VALARM" > component it uniquely identifies the instances of the "VALARM" > within a component. s/within a component/within its parent component/? (for clarity) > 2.1.2 New Properties (summary) The style of definition here is different from the preceding section. In 2.1.1, most of the defs used the parameter name right away ("The "OPTIONS" parameter blah blah blah"), whereas many of these specify it near the end or not at all ("The CAP commands, as well as replies are transmitted using the "CMD" property" [which needs a comma after "replies" btw]). Also, some of the "definitions" are actually rationales. Eg: > ALLOW-CONFLICT - Some entries in a calendar might not be valid if > other entries were allowed to overlap the same time span. > (Section 8.1) which does not define ALLOW-CONFLICT. Likewise for ATT-COUNTER. > CAP-VERSIN typo > CAR-LEVEL - The level of calendar access level supported. remove the second "level" > DEFAULT-CHARSET - The list of charsets supported by the CS Ugh. Probably too late to change this (and DEFAULT-LOCALE and DEFAULT-TZID) to "SUPPORTED-CHARSETS" or something? (Especially since "DEFAULT-VCARS" really does mean "default VCARs".) > EXPAND - This property tells the CS if the query reply should expand > components into multiple instances. The default is FALSE. None of the other properties mention a default. Does that belong here? > MAXDATE - The maximum date supported by the CS. (Section 8.20) > MINDATE - The minimum date supported by the CS. (Section 8.21) MAXDATE and MINDATE are fine names for protocol elements, but the English description would read better with "latest" and "earliest". > RECUR-ACCEPTED - If the implementation support recurrence rules. > RECUR-EXPAND - If the implementation support expanding recurrence s/support/supports/ in both > REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to > include new error numbers. (Section 8.28) That should be in section 2 rather than 2.1.2 then, right? Likewise TRANSP. Either that or 2.1.2 should be "New and Modified Properties" > VAGENDA - CAP allows the fetching and storing of the entire contents > of a calendar. The "VCALENDAR" component is not sufficient to > encapsulate all of the needed data that describes a calendar. The second sentence is wrong, right? VCALENDAR is used to encapsulate complete CAP commands/replies, VAGENDA is used to encapsulate calendars inside VCALENDARs. > 2.2 Relationship of RFC-2446 (ITIP) and CAP This section is really hard to understand, but I don't have any concrete suggestions right now. 'marked for delete state' should be '"DELETED" state' everywhere for consistency. ? > 3.3.1 Use of BEEP, MIME, and iCalendar > The [BEEP] data exchanged in CAP is a iCalendar MIME content that > fully conforms to [iCAL] iCalendar format. Fix "a iCalendar". I wasn't paying attention to the whole multipart flame war, but did people agree that this is supposed to mean "The Content-Type of [BEEP] data exchanged in CAP is always text/calendar"? If so, it would be nice to be explicit about that. > 4.2.1 Access Control and NOCONFLICT > > The "TRANSP" property can take on values "TRANSPARENT-NOCONFLICT" and > "OPAQUE-NOCONFLICT" that prohibit other components from overlapping > it. This setting overrides access. I don't think this section is necessary (or even correct). "Overrides access" implies that if I don't have any access to a given calendar, and I try to create an appointment in it that would overlap an NOCONFLICT appointment, then I should get a 6.2 (overlap error) instead of a 6.4 (permissions error), because NOCONFLICT overrides access. What I think it really is supposed to mean is "even if you have permission to write to a calendar, you can't make an appointment that overlaps a NOCONFLICT appointment". But that's not a permissions-related thing, and it doesn't need to be explicitly stated any more than "even if you have permission to write to a calendar you can't make an appointment that ends before it starts". (If you do keep this section, the final sentence in it refers to the wrong error code. It says 6.3 but should say 6.2.) > 4.2.2 Predefined VCARs > CARID:REQUESTONLY - Specifies the "GRANT" and "DENY" rules to UPNs > other than the owner of the calendar the ability to write new > objects with the property "METHOD" property set to the "REQUEST" delete first "property" > 4.2.3 Decreed VCARs > To the CUA any "VCAR" component with the "DECREED" property set to > "TRUE" can not be changed by the currently authenticated UPN, and > depending on the implementation and other "VCAR" components; might not > be able to be changed by any UPN using CAP, and never when the CUA > gets a "DECREED:TRUE" VCAR. s/;/,/ I think everything after the last comma is a remnant of a previous wording and needs to be deleted. > When a user attempts to modify or override a decreed "VCAR" component > rules an error will be returned indicating that the user has s/ rules/,/ (or maybe just s/rules/rule,/ ?) > 4.3 CAP Session Identity > A UPN with a non-null Username and null Realm, such as "bob@" could be > a security risk and MUST NOT be used. That's silly. It invents a security hole and then tells you not to use it. It should just say that that's not a UPN. (And in fact, the ABNF for "upn" doesn't allow that.) > 5. CAP URL and Calendar Address s/RFC 2396/[URI]/ throughout, and likewise fix "RFC 2718" refs From owner-ietf-calendar@mail.imc.org Wed Apr 2 10:13:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12891 for ; Wed, 2 Apr 2003 10:13:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EvhJM006587 for ; Wed, 2 Apr 2003 06:57:43 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32EvhMA006585 for ietf-calendar-bks; Wed, 2 Apr 2003 06:57:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EvfJM006577 for ; Wed, 2 Apr 2003 06:57:42 -0800 (PST) In-Reply-To: <3E89EF4E.6080503@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 09:45:29 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 09:57:25 AM, Serialize complete at 04/02/2003 09:57:25 AM Content-Type: multipart/alternative; boundary="=_alternative 0050C77585256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050C77585256CFC_= Content-Type: text/plain; charset="US-ASCII" Doug noted on 04/01/2003 02:58:06 PM: > Need told me and Pat repeated that we can not add features to CAP > unless 20 people on this list insist tht it must be done. We > are shipping CAP soon ! :-) Passing WG Last Call is what we all want but if it just goes to the next step and someone raises the issue of "Hey, this 'Scheduling' protocol has no way to get busytime information. Why not?" then its gonna come back to us for fixing since I think that we all agree its not a minor quibble over textual phrasing. Keeping feature creep out is very critical as we go that last mile to passing Last Call but this is NOT a "I want to be able request entries in the color Blue" kind of feature request; its a fairly basic usablity feature we havent clearly defined IMHO. > I am in the processing of updating my CUA-BOT draft (never sent) > as an add-on to CAP. FWIW, adding 'Bots' to a CS is invisible to all but the CS Admins. CUs/CUAs only see the functionality thru commands, returned results or GET-CAPABILITY responses so they dont know/care if its a Bot, Perl script or highly polished C++ code. Still, Id be interested in reading your proposal (even offline). 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 0050C77585256CFC_= Content-Type: text/html; charset="US-ASCII"
Doug noted on 04/01/2003 02:58:06 PM:
> Need told me and Pat repeated that we can not add features to CAP
> unless 20 people on this list insist tht it must be done. We
> are shipping CAP soon ! :-)
Passing WG Last Call is what we all want but if it just goes to the next step and someone raises the issue of "Hey, this 'Scheduling' protocol has no way to get busytime information.  Why not?" then its gonna come back to us for fixing since I think that we all agree its not a minor quibble over textual phrasing.

Keeping feature creep out is very critical as we go that last mile to passing Last Call but this is NOT a "I want to be able request entries in the color Blue" kind of feature request; its a fairly basic usablity feature we havent clearly defined IMHO.

> I am in the processing of updating my CUA-BOT draft (never sent)
> as an add-on to CAP.
FWIW, adding 'Bots' to a CS is invisible to all but the CS Admins.  CUs/CUAs only see the functionality thru commands, returned results or GET-CAPABILITY responses so they dont know/care if its a Bot, Perl script or highly polished C++ code.  Still, Id be interested in reading your proposal (even offline).

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 0050C77585256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 10:14:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13080 for ; Wed, 2 Apr 2003 10:14:54 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EvhJM006598 for ; Wed, 2 Apr 2003 06:57:43 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32EvhqA006597 for ietf-calendar-bks; Wed, 2 Apr 2003 06:57:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32EvfJN006577 for ; Wed, 2 Apr 2003 06:57:42 -0800 (PST) In-Reply-To: <3E89EFC3.5050602@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 09:57:41 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 09:57:26 AM, Serialize complete at 04/02/2003 09:57:26 AM Content-Type: multipart/alternative; boundary="=_alternative 0051E55985256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0051E55985256CFC_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 04/01/2003 03:00:03 PM: > > Having VFREEBUSY info > > unrepresentable of the actual calendar data makes it useless for its > > intended purpose. > > No. It means that CAP does not specify it. It does not mean that > it can not be specified. Perhaps we are talking about different things. Im saying that if a CUA can craft any arbitrary VFREEBUSY data then it is very unlikely that the VFREEBUSY data I get from your calendar actually represents your busytime as VFREEBUSY data was designed and intended to do. That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today but the VFREEBUSY data on my calendar says Im FREEBUSY:20030402T060000Z/20030402T063000Z. This makes busytime useless for trying to schedule with me. CAP 1.0 currently allows (in theory) the ability for a CUA to CREATE or modify ANY component type. This means that A) there is an implict burden on CUAs to maintain VFREEBUSY data to be in sync w/the calendar contents or B) VFREEBUSY data is an unreliable/useless mechanism in CAP. I dont think we disagree about the need, I think Im just hearing that "The ADs want this critter out now so we cannot address it in CAP 1.0". Can I start stuffing the ballot box w/lurker votes to get the required 20??... :^b BTW: I dont think I saw an answer as to where my CUA would/should poll in order to get the iTIP VFREEBUSY REPLY. Would that be a magically created UNPROCESSED document in _my_ calendar that I would have to SEARCH for? 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 0051E55985256CFC_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 04/01/2003 03:00:03 PM:
>  >  Having VFREEBUSY info
> > unrepresentable of the actual calendar data makes it useless for its
> > intended purpose.
>
> No. It means that CAP does not specify it. It does not mean that
> it can not be specified.
Perhaps we are talking about different things.  Im saying that if a CUA can craft any arbitrary VFREEBUSY data then it is very unlikely that the VFREEBUSY data I get from your calendar actually represents your busytime as VFREEBUSY data was designed and intended to do.

That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today but the VFREEBUSY data on my calendar says Im FREEBUSY:20030402T060000Z/20030402T063000Z.  This makes busytime useless for trying to schedule with me.

CAP 1.0 currently allows (in theory) the ability for a CUA to CREATE or modify ANY component type.  This means that A) there is an implict burden on CUAs to maintain VFREEBUSY data to be in sync w/the calendar contents or B) VFREEBUSY data is an unreliable/useless mechanism in CAP.

I dont think we disagree about the need, I think Im just hearing that "The ADs want this critter out now so we cannot address it in CAP 1.0".  Can I start stuffing the ballot box w/lurker votes to get the required 20??... :^b

BTW: I dont think I saw an answer as to where my CUA would/should poll in order to get the iTIP VFREEBUSY REPLY.  Would that be a magically created UNPROCESSED document in _my_ calendar that I would have to SEARCH for?

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 0051E55985256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 10:42:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14367 for ; Wed, 2 Apr 2003 10:42:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FI3JM008729 for ; Wed, 2 Apr 2003 07:18:03 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32FI3ha008728 for ietf-calendar-bks; Wed, 2 Apr 2003 07:18:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32FI2JM008707 for ; Wed, 2 Apr 2003 07:18:02 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040210222109822 for ; Wed, 02 Apr 2003 10:22:21 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 10:15:37 -0500 Message-ID: <3E8AFE99.50707@centive.com> Date: Wed, 02 Apr 2003 10:15:37 -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: CAP & busytime? - not CAP reqirement - CUA-BOT References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 15:15:37.0847 (UTC) FILETIME=[B744B070:01C2F92A] 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 am in the processing of updating my CUA-BOT draft (never sent) > > as an add-on to CAP. > > FWIW, adding 'Bots' to a CS is invisible to all but the CS Admins. > CUs/CUAs only see the functionality thru commands, returned results > or GET-CAPABILITY responses so they dont know/care if its a Bot, In this case, people would care, because a bot could not update the freebusy information immediately (we don't have notifications of changes), so there would always be a lag between adding an event and seeing the updated VFREEBUSY. And admins would resent the performance cost of having those bots polling all the time, so they would try to keep that poll interval long, which would make that lag worse. Performance would probably be better if the VFREEBUSY were being generated in the CS. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 10:42:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14369 for ; Wed, 2 Apr 2003 10:42:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FJgJM008942 for ; Wed, 2 Apr 2003 07:19:42 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32FJgFR008941 for ietf-calendar-bks; Wed, 2 Apr 2003 07:19:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FJfJM008935 for ; Wed, 2 Apr 2003 07:19:41 -0800 (PST) To: ietf-calendar@imc.org Subject: iTIP Bug: VFREEBUSY REPLYs MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 10:19:27 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 10:19:42 AM, Serialize complete at 04/02/2003 10:19:42 AM Content-Type: multipart/alternative; boundary="=_alternative 0053E38585256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053E38585256CFC_= Content-Type: text/plain; charset="US-ASCII" In spending some cycles checking something I noticed a conflict between RFCs 2445 and 2446. In 2445, Section 4.6.4 Free/Busy Component we wrote: When used to reply to a request for free/busy time, the "ATTENDEE" property specifies the calendar user responding to the free/busy time request; the "ORGANIZER" property specifies the calendar user that originally requested the free/busy time; the "FREEBUSY" property specifies the free/busy time information (if it exists); and the "UID" and "DTSTAMP" properties are specified to assist in proper sequencing of multiple free/busy time replies. and in 2446, Section 3.3.2 REPLY we have the restriction table with: DTEND 1 DateTime values must be in UTC DTSTART 1 DateTime values must be in UTC FREEBUSY 1+ (values MUST all be of the same data type. Multiple instances are allowed. Multiple instances MUST be sorted in ascending order. Values MAY NOT overlap) There are 2 discrepancies: 1: There is no mention of DTSTART/DTEND in 2445 but its in the restriction table for 2446 2: The restriction table in 2446 says 1+ for FREEBUSY but 2445 clearly says "if it exists" For #1, I think we can remove the DTSTART/DTEND from 2446 since the REQUEST was the one to specify the desired range, the REPLY only has to return the data for that range. For #2, I think that we need to change the restriction table in 2446 to: FREEBUSY 0+ (values MUST all be of the same data so that we can accurately return "There are no entries for the requested range". Sending back an 'emtpy' FREEBUSY is a poor hack... Bruce PS: Anyone recall why we would say "Values MAY NOT overlap" in the table since multiple bookings are legit??... =========================================================================== 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 0053E38585256CFC_= Content-Type: text/html; charset="US-ASCII"
In spending some cycles checking something I noticed a conflict between RFCs 2445 and 2446.  In 2445, Section 4.6.4 Free/Busy Component we wrote:

   When used to reply to a request for free/busy time, the "ATTENDEE"
  property specifies the calendar user responding to the free/busy time
  request; the "ORGANIZER" property specifies the calendar user that
  originally requested the free/busy time; the "FREEBUSY" property
  specifies the free/busy time information (if it exists); and the
  "UID" and "DTSTAMP" properties are specified to assist in proper
  sequencing of multiple free/busy time replies.
and in 2446, Section 3.3.2 REPLY we have the restriction table with:

    DTEND           1      DateTime values must be in UTC
   DTSTART         1      DateTime values must be in UTC
   FREEBUSY        1+      (values MUST all be of the same data
                           type. Multiple instances are allowed.
                           Multiple instances MUST be sorted in
                           ascending order. Values MAY NOT overlap)

There are 2 discrepancies:

1: There is no mention of DTSTART/DTEND in 2445 but its in the restriction table for 2446
2: The restriction table in 2446 says 1+ for FREEBUSY but 2445 clearly says "if it exists"

For #1, I think we can remove the DTSTART/DTEND from 2446 since the REQUEST was the one to specify the desired range, the REPLY only has to return the data for that range.  

For #2, I think that we need to change the restriction table in 2446 to:
    FREEBUSY        0+      (values MUST all be of the same data
so that we can accurately return "There are no entries for the requested range".  Sending back an 'emtpy' FREEBUSY is a poor hack...

Bruce
PS: Anyone recall why we would say "Values MAY NOT overlap" in the table since multiple bookings are legit??...
===========================================================================
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 0053E38585256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 10:52:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14699 for ; Wed, 2 Apr 2003 10:52:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FbxJM010950 for ; Wed, 2 Apr 2003 07:37:59 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Fbx7q010949 for ietf-calendar-bks; Wed, 2 Apr 2003 07:37:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32FbwJM010941 for ; Wed, 2 Apr 2003 07:37:58 -0800 (PST) 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 h32FbtM4028903 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 07:37:58 -0800 Message-ID: <3E8B03CA.4010601@Royer.com> Date: Wed, 02 Apr 2003 08:37:46 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060101010801050305030203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060101010801050305030203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug noted on 04/01/2003 02:58:06 PM: > > Need told me and Pat repeated that we can not add features to CAP > > unless 20 people on this list insist tht it must be done. We > > are shipping CAP soon ! :-) > > Passing WG Last Call is what we all want but if it just goes to the next > step and someone raises the issue of "Hey, this 'Scheduling' protocol > has no way to get busytime information. You already know that the above is not true. The CUA can do a SEARCH for VFREEBUSY components. So I have no idea how to respond to your conclusion based on your assertion. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060101010801050305030203 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIxNTM3NDZaMCMGCSqGSIb3DQEJBDEWBBTt UJHVcPUmxl5uvmZC6blZLHAYRTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAdO+pr/hQhm/I Br2cYJUONNzYFkH+/RioOZSYMc9RKql4GLkvQ3FGI9vEXO5YHF1gF29ikYSSbAs1K1hNRsrE KhuKG7UQApwmXQqx1bUqUbhmCcs/+4IZ/Bfhlv9DydUdG2YVAuXe5QQIUjfjcETXlib1tYfF Ol44j6j0KEe+0YRu/64ulUUzajSOpLJdl4gT9QHGM7gaXxO/cSsue1DmwzChkUP+GOX0aUwt m+FCZ8f2rvF56gsEtYagP5K9r2g1L3aKWDR6lec5h4S49NSBLTrP1x8MYcMhRMufUofzjaJd tmgXaZLvroO+aiCIvRJgVk/DwIV0vHF0sLoZy/M2DgAAAAAAAA== --------------ms060101010801050305030203-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 10:54:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14723 for ; Wed, 2 Apr 2003 10:54:27 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FaxJM010793 for ; Wed, 2 Apr 2003 07:36:59 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32FaxB7010792 for ietf-calendar-bks; Wed, 2 Apr 2003 07:36:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FawJM010782 for ; Wed, 2 Apr 2003 07:36:58 -0800 (PST) In-Reply-To: <3E89F3D8.1050508@centive.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 10:25:08 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 10:36:59 AM, Serialize complete at 04/02/2003 10:36:59 AM Content-Type: multipart/alternative; boundary="=_alternative 005468D885256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005468D885256CFC_= Content-Type: text/plain; charset="US-ASCII" John replied on 04/01/2003 03:17:28 PM: > > And make each CUA consume even more cycles rebuilding VFREEBUSY data > > and resending it. Hmm, lets weigh that against having the CS do it > > automatically at a reduced cost in CUA load (thus better CUA > > performance) and network bandwidth in addition to the CS resources > > consumed to just deal with the added traffic. > > Note that this isn't necessarily conclusive--techniques for serving up > relatively static data are well-known (think Web servers); it's usually > cheaper than server-side processing. I think you miss the scenario. Short of maintaining a single VFREEBUSY with a single FREEBUSY property for _every_ calendar entry, there is NO quick or simple way for a CUA to find and update the VFREEBUSY that represents the amalgamation of multiple entries. Even in the simplest case if you have 2 entries that overlap the CUA has to be sure to SEARCH for and update the correct VFREEBUSY. (Remember that the UID in the VFREEBUSY is NOT the UID of the entry represented by any FREEBUSY property so its NOT a linkage mechanism!) Since calendars change and can change frequently its not an issue of serving up a staticly generate response since a busytime request is a bounded response ("Give me Johns busytime between DTSTART and DTEND" where I can provide ANY values for DTSTART and DTEND I want. They are NOT going to always match any statically generated VFREEBUSY data, esp. in the amalgamated case. Since there are going to be 'thin' and 'thick' CUAs built and not every one will have all the ability to properly regenerate VFREEBUSY that accuratly reflect the calendar status I strongly think the onus for dealing with busytime belong on the CS and nowhere else. In any case I think we are in violent agreement here (at least were were earlier). > > As such the CUA wont have to sort thru all the VFREEBUSY data for my > > entire calendar starting back in 1996 thru 2045 (dont ask!); > > You pre-expand repeating events, and cut them off after 50 years? You asked... :^) I didnt plan for stuff after the 50th wedding anniversary; thats going to be hard to top and Ill leave that to my twins to do... > It sounds like > the current plan is that the CS treats VFREEBUSY components as opaque, > and just stores/delivers them for CUAs; in that case, the CS has to > return the entirety of every VFREEBUSY that overlaps the requested > range. If there's only one per CU, that means every VFREEBUSY request > will return all the data. Ugh! What a waste and a kludge! In 2445 we clearly said that the requestor could bound the interval of interest and by just sending back a single "Heres my entire busytime" blob is an abuse of the system. The original expectation was that the response would ONLY contain data relevant to that interval, not data for any arbitrary interval. > If, on the other hand, a CS is supposed to maintain freebusy data as > data, and construct a VFREEBUSY from that data on request, then it's > doing almost as much work as constructing a VFREEBUSY on request based > on VEVENT data. As expected, we are in violent agreement (although according to Doug this is an old issue and one the WG rejected but Im not so sure of that...) Now we just need 18 more folks to chime in and we can fix it before Last Call... 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 005468D885256CFC_= Content-Type: text/html; charset="US-ASCII"
John replied on 04/01/2003 03:17:28 PM:
> > And make each CUA consume even more cycles rebuilding VFREEBUSY data
> > and resending it.  Hmm, lets weigh that against having the CS do it
> > automatically at a reduced cost in CUA load (thus better CUA
> > performance) and network bandwidth in addition to the CS resources
> > consumed to just deal with the added traffic.
>
> Note that this isn't necessarily conclusive--techniques for serving up
> relatively static data are well-known (think Web servers); it's usually
> cheaper than server-side processing.
I think you miss the scenario.  Short of maintaining a single VFREEBUSY with a single FREEBUSY property for _every_ calendar entry, there is NO quick or simple way for a CUA to find and update the VFREEBUSY that represents the amalgamation of multiple entries.  Even in the simplest case if you have 2 entries that overlap the CUA has to be sure to SEARCH for and update the correct VFREEBUSY.  (Remember that the UID in the VFREEBUSY is NOT the UID of the entry represented by any FREEBUSY property so its NOT a linkage mechanism!)

Since calendars change and can change frequently its not an issue of serving up a staticly generate response since a busytime request is a bounded response ("Give me Johns busytime between DTSTART and DTEND" where I can provide ANY values for DTSTART and DTEND I want.  They are NOT going to always match any statically generated VFREEBUSY data, esp. in the amalgamated case.

Since there are going to be 'thin' and 'thick' CUAs built and not every one will have all the ability to properly regenerate VFREEBUSY that accuratly reflect the calendar status I strongly think the onus for dealing with busytime belong on the CS and nowhere else.

In any case I think we are in violent agreement here (at least were were earlier).

> > As such the CUA wont have to sort thru all the VFREEBUSY data for my
> > entire calendar starting back in 1996 thru 2045 (dont ask!);
>
> You pre-expand repeating events, and cut them off after 50 years?
You asked... :^)

I didnt plan for stuff after the 50th wedding anniversary; thats going to be hard to top and Ill leave that to my twins to do...

>                                                        It sounds like
> the current plan is that the CS treats VFREEBUSY components as opaque,
> and just stores/delivers them for CUAs; in that case, the CS has to
> return the entirety of every VFREEBUSY that overlaps the requested
> range.  If there's only one per CU, that means every VFREEBUSY request
> will return all the data.
Ugh!  What a waste and a kludge!  

In 2445 we clearly said that the requestor could bound the interval of interest and by just sending back a single "Heres my entire busytime" blob is an abuse of the system.  The original expectation was that the response would ONLY contain data relevant to that interval, not data for any arbitrary interval.

> If, on the other hand, a CS is supposed to maintain freebusy data as
> data, and construct a VFREEBUSY from that data on request, then it's
> doing almost as much work as constructing a VFREEBUSY on request based
> on VEVENT data.
As expected, we are in violent agreement (although according to Doug this is an old issue and one the WG rejected but Im not so sure of that...)  Now we just need 18 more folks to chime in and we can fix it before Last Call...

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 005468D885256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 10:57:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14823 for ; Wed, 2 Apr 2003 10:57:53 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FeDJM011272 for ; Wed, 2 Apr 2003 07:40:13 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32FeCR3011270 for ietf-calendar-bks; Wed, 2 Apr 2003 07:40:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32FeBJM011264 for ; Wed, 2 Apr 2003 07:40:11 -0800 (PST) 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 h32Fe8M4028934 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 07:40:11 -0800 Message-ID: <3E8B0452.9070107@Royer.com> Date: Wed, 02 Apr 2003 08:40:02 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010105010909060908000901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010105010909060908000901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > I am in the processing of updating my CUA-BOT draft (never sent) > > as an add-on to CAP. > > FWIW, adding 'Bots' to a CS is invisible to all but the CS Admins. > CUs/CUAs only see the functionality thru commands, returned results or > GET-CAPABILITY responses so they dont know/care if its a Bot, Perl > script or highly polished C++ code. Still, Id be interested in reading > your proposal (even offline). Its effect is visible to the CU and CUA which is its purpose. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010105010909060908000901 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIxNTQwMDJaMCMGCSqGSIb3DQEJBDEWBBTV RvSsB1lkxOsaRlyO4obYThVBfDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAaXk+Wt6EiaE7 HxfdllaVUG2M0Zt9kN9ycSFeLnTjaMMID3SGhOJSaonDLjqvk/30TlklfBYfQGl52nMwfVAv 4n1CWjgalvsS42m8l1sYVr5hsIQqcWQkckhA+U6XpxkdTd0zIXrhSEyXJwi5ADwdKm54XyTw AeK2nrzd9DKr6WbPhesMjxD/rv69EqQ9Q21sTPbV83ReuwXgB+uDl3Dgq6wfugbW3KEj+0f8 Pztnt2xE+Z59jjA+Z61HHVL/nQwMKY9pXHLPGitGS3x26X+2SL4Dle2DeNCT/xjlUurWBUDw 2AMSEQeilw4hem0ksmbbzNE91WDnVIoMD7XUGtjCnwAAAAAAAA== --------------ms010105010909060908000901-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 11:16:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15499 for ; Wed, 2 Apr 2003 11:16:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FxEJM014093 for ; Wed, 2 Apr 2003 07:59:14 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32FxEPT014092 for ietf-calendar-bks; Wed, 2 Apr 2003 07:59:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32FxCJM014084 for ; Wed, 2 Apr 2003 07:59:12 -0800 (PST) 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 h32FxAM4029058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 07:59:13 -0800 Message-ID: <3E8B08C4.7060209@Royer.com> Date: Wed, 02 Apr 2003 08:59:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040700020005080500020108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040700020005080500020108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 04/01/2003 03:00:03 PM: > > > Having VFREEBUSY info > > > unrepresentable of the actual calendar data makes it useless for its > > > intended purpose. > > > > No. It means that CAP does not specify it. It does not mean that > > it can not be specified. > > Perhaps we are talking about different things. Im saying that if a CUA > can craft any arbitrary VFREEBUSY data then it is very unlikely that the > VFREEBUSY data I get from your calendar actually represents your > busytime as VFREEBUSY data was designed and intended to do. I think that it is less likely that we in this WG can draft a document that will reflect what every CU and vertical application will want in the VFREEBUSY data presented. Adding a BOT that gets it done will allow the vendors to select what is or is not included without having to specify at this time the procedure to create the VFREEBUSY object. > That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today > but the VFREEBUSY data on my calendar says Im > FREEBUSY:20030402T060000Z/20030402T063000Z. This makes busytime useless > for trying to schedule with me. For some resource calendars that may be valid. Only the CUA/CU and perhaps the CS knows. Maybe the resources for that time slot are not filled up. > CAP 1.0 currently allows (in theory) the ability for a CUA to CREATE or > modify ANY component type. This means that A) there is an implict > burden on CUAs to maintain VFREEBUSY data to be in sync w/the calendar > contents or B) VFREEBUSY data is an unreliable/useless mechanism in CAP. (A) is not completely true. It is your assertion that the VFREEBUSY time must be 'in sync'. I could have different constraints such as blocking out 9PM-6AM in the VFREEBUSY and never allowing any component to book at those times. My VFREEBUSY time and the objects in my calendar would then never be in sync. I could insert data in my VFREEBUSY time for a 1 week vacation and not (see previous e-mail) have X number of OPAQUE entries in my calendar for the 1 week vacation. (B) is your opinion. I think it is just as likely that a CUA could be busted in several ways (B) being only one of them. > I dont think we disagree about the need, I think Im just hearing that > "The ADs want this critter out now so we cannot address it in CAP 1.0". > Can I start stuffing the ballot box w/lurker votes to get the required > 20??... :^b We do disagree. I agree that something must create the VFREEBUSY time and I do not think that this WG can determine the how the data in VFREEBUSY objects are created. And I think we disagree in our thinking that the VFREEBUSY time and components in the calendar must be 'in sync'. The VFREEBUSY time must be in sync with what the CU wants, not all objects in the calendar. I am saying that this is a topic in itself and does not need to be in CAP. > BTW: I dont think I saw an answer as to where my CUA would/should poll > in order to get the iTIP VFREEBUSY REPLY. Would that be a magically > created UNPROCESSED document in _my_ calendar that I would have to > SEARCH for? We also squashed notifications (yet another draft I have written waiting for CAP). That will allow you to not have to POLL for anything - including VFREEBUYSY. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040700020005080500020108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIxNTU5MDBaMCMGCSqGSIb3DQEJBDEWBBRx IdK2zBSsUufCMyHfinIMr1II3jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAUznAokwP0evR zUMem5NJ8GAYgo74aeblQ542CwRHmWNTmkzHKaErsRkNpraeWVhK6Hxnjl0+Q+f9YP4XkHLf WYe/7x3GNqOv7Jyl1XRtDj90L5KfCaFk/AAtCx0sS3jmH4AUrKk4HCipVtKMaED1bEWEmKNb YoHemQ3Vy0tosPdbBcuaUhVgmr/mj9CAAixj7sC9QJCInyzS4lxI2o9fudtvbDOOZQHbp9wb XdhNGV2RsxHZySoskeaz2mQcYOtfYeAKFiG2kLTFeEaujfqQKYmi8zlbhx9subYQ3VLGx4+L +IGKTg2F3IR4TwyXLPwYITMWg2Uy5oWWwhaSpzIAaAAAAAAAAA== --------------ms040700020005080500020108-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 11:19:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15655 for ; Wed, 2 Apr 2003 11:19:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32FskJM013419 for ; Wed, 2 Apr 2003 07:54:46 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Fsk8o013418 for ietf-calendar-bks; Wed, 2 Apr 2003 07:54:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32FsjJM013396 for ; Wed, 2 Apr 2003 07:54:45 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040210591318155 for ; Wed, 02 Apr 2003 10:59:13 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 10:52:29 -0500 Message-ID: <3E8B073D.5090604@centive.com> Date: Wed, 02 Apr 2003 10:52:29 -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: calsch Subject: Re: iTIP Bug: VFREEBUSY REPLYs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 15:52:29.0792 (UTC) FILETIME=[DDB0B600:01C2F92F] 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 think we can remove the DTSTART/DTEND from 2446 since the REQUEST > was the one to specify the desired range, the REPLY only has to return > the data for that range. But the REPLY might be compiled for a wider range than was requested (for example, if the replying CUA has VFREEBUSYs cached for each month), and it would be useful to know the actual range it applies to. If the inviter asks for freebusy time for one week, and can't come up with anything that matches, it'd be nice to know that it already has freebusy time for a whole month, and doesn't need to request it again. On the other hand, if the request was for a whole month, and the replying CUA has VFREEBUSYs cached by week, the REPLY might contain multiple VFREEBUSYs, and it can use the DTSTART/DTENDs to assemble them. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 11:24:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15907 for ; Wed, 2 Apr 2003 11:24:51 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32G0tJM014356 for ; Wed, 2 Apr 2003 08:00:55 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32G0tVW014355 for ietf-calendar-bks; Wed, 2 Apr 2003 08:00:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32G0sJM014350 for ; Wed, 2 Apr 2003 08:00:54 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP Editoral: Acronyms in Section 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 11:00:51 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 11:00:53 AM, Serialize complete at 04/02/2003 11:00:53 AM Content-Type: multipart/alternative; boundary="=_alternative 0057ADF385256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057ADF385256CFC_= Content-Type: text/plain; charset="US-ASCII" In showing CAP to someone they started to read Section 1 Introduction and were somewhat confused by the yet undefined acronyms it used: This document specifies how a Calendar CUA interacts with a CS to manage calendar information. In particular, it specifies how to query, create, modify, and delete iCalendar components (e.g., events, to-dos, or daily journal entries). It further specifies how to search for available busy time information. Synchronization with CUAs is not covered. CAP is specified as a [BEEP] "profile". As such, many aspects of the protocol (e.g., authentication and privacy) are provided within [BEEP]. The protocol data units leverage the standard iCalendar format [iCAL] to convey calendar related information. CAP can also be used to store and fetch [iTIP] objects and when those objects are used in this memo, they mean exactly the same as defined in [iTIP]. When iCalendar objects are transfered between the CUA and a CS, some additional properties and parameters may be added and the CUA is responsible for correctly generating iCalendar objects to non CAP processes. The terms CS and CUA are not defined until Section 1.3 so could we please expand them to "Calendar Server" and Calendar User Agent until we define them later in the text? Plus a "Calendar CUA" is a bit of a verbose redundancy... 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 0057ADF385256CFC_= Content-Type: text/html; charset="US-ASCII"
In showing CAP to someone they started to read Section 1 Introduction and were somewhat confused by the yet undefined acronyms it used:

This document specifies how a Calendar CUA interacts with a CS to manage calendar information. In particular, it specifies how to query, create, modify, and delete iCalendar components (e.g., events, to-dos, or daily journal entries). It further specifies how to search for available busy time information. Synchronization with CUAs is not covered.

CAP is specified as a [BEEP] "profile". As such, many aspects of the protocol (e.g., authentication and privacy) are provided within [BEEP]. The protocol data units leverage the standard iCalendar format [iCAL] to convey calendar related information.

CAP can also be used to store and fetch [iTIP] objects and when those objects are used in this memo, they mean exactly the same as defined in [iTIP]. When iCalendar objects are transfered between the CUA and a CS, some additional properties and parameters may be added and the CUA is responsible for correctly generating iCalendar objects to non CAP processes.

The terms CS and CUA are not defined until Section 1.3 so could we please expand them to "Calendar Server" and Calendar User Agent until we define them later in the text?  Plus a "Calendar CUA" is a bit of a verbose redundancy...

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 0057ADF385256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 11:27:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16038 for ; Wed, 2 Apr 2003 11:27:21 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32G3YJM014641 for ; Wed, 2 Apr 2003 08:03:34 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32G3YRd014640 for ietf-calendar-bks; Wed, 2 Apr 2003 08:03:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32G3XJM014636 for ; Wed, 2 Apr 2003 08:03:33 -0800 (PST) In-Reply-To: <3E8A312F.4030801@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 11:02:08 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 11:03:32 AM, Serialize complete at 04/02/2003 11:03:32 AM Content-Type: multipart/alternative; boundary="=_alternative 0057CBF185256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057CBF185256CFC_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 04/01/2003 07:39:11 PM: > In effect you have a mini-CUA (BOT) built into > your CS that deposits (from the CUA's point of view) VFREEBUSY > components into each calendar (when in reality you probably > generate them dynamically and on the fly). > > I do not see that you are breaking CAP. Ya cant break what isnt specified... > One of the reasons that we dropped automatically processing > VFREEBUSY processing on the CS was there is going to be > a LARGE debate on how its contents are going to be generated. Can you please refresh me on when the WG kaiboshed us on doing this automatically in the CS? I still cant find it in any archives... > Must I include all OPAQUE object times? Why not? That status is conveyed in the fbtypeparam: fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" / x-name ; Some experimental iCalendar data type. / iana-token) and I think that CAP needs to expand this list to include the new properties that it defined for TRANParent. > What if I do not want to? Why not indicate "Im busy from 9AM-9:30AM Today" when you really are? Why would you want someone to think you were avaiable when you're already booked? Isn't that the purpose of busytime, to tell folks when you are busy?? > Would I have to make entries in my company calendar > that block out closed times? Nice ideas. We've had some in Notes since Notes 4.5. Again though nothing prevents my boss from scheduling a meeting 'after hours' if he wants to... > What if I want ... [Snip, snip] Nothing preventing you from building this but Id say that some of what you want is better left for post-CAP 1.0... > I think it is best left to a separate draft. Adding features and bells/whistles like you want I agree is best left for after CAP 1.0. I think that a clear busytime system needs to be in CAP 1.0 though! However this still does not address my original question about HOW does CAP specify busytime query/retrieval. Using iTIP REQUEST/REPLY appears to be your response but where do I query to get the REPLYs from you, Pat and Bob? Do I SEARCH my UNPROCESSED docs?? Ugh! Thats really I strongly think that that approach is the wrong one to take and that CAP should have a clearer and better mechanism for doing this. From the skimming of the flurry of msgs today I get the impression that dynamic data is the way we all think it should go (we just disagree about how to extend it I think). For CAP 1.0 we can simply say that the CS returns data is reflective of the TARGETs contents "subject to Administrative policies" and that the CS is responsible for maintaining the VFREEBUSY in the store/calendar (NOT the CUA!). You can then build your bells/whistles features as such and thus provide the nifty features to any CAP client. Of course to even try this we need more votes... Ive seen 4 so far. Do I count you as #5 Doug? 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 0057CBF185256CFC_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 04/01/2003 07:39:11 PM:
>                 In effect you have a mini-CUA (BOT) built into
> your CS that deposits (from the CUA's point of view) VFREEBUSY
> components into each calendar (when in reality you probably
> generate them dynamically and on the fly).
>
> I do not see that you are breaking CAP.
Ya cant break what isnt specified...

> One of the reasons that we dropped automatically processing
> VFREEBUSY processing on the CS was there is going to be
> a LARGE debate on how its contents are going to be generated.
Can you please refresh me on when the WG kaiboshed us on doing this automatically in the CS?  I still cant find it in any archives...

>    Must I include all OPAQUE object times?
Why not?  That status is conveyed in the fbtypeparam:

     fbtypeparam        = "FBTYPE" "=" ("FREE" / "BUSY"
                       / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE"
                       / x-name
       ; Some experimental iCalendar data type.
                       / iana-token)

and I think that CAP needs to expand this list to include the new properties that it defined for TRANParent.

>    What if I do not want to?

Why not indicate "Im busy from 9AM-9:30AM Today" when you really are?  Why would you want someone to think you were avaiable when you're already booked?    Isn't that the purpose of busytime, to tell folks when you are busy??

>    Would I have to make entries in my company calendar
>    that block out closed times?

Nice ideas.  We've had some in Notes since Notes 4.5.  

Again though nothing prevents my boss from scheduling a meeting 'after hours' if he wants to...

>                                  What if I want ...
[Snip, snip]
Nothing preventing you from building this but Id say that some of what you want is better left for post-CAP 1.0...

> I think it is best left to a separate draft.
Adding features and bells/whistles like you want I agree is best left for after CAP 1.0.  I think that a clear busytime system needs to be in CAP 1.0 though!  

However this still does not address my original question about HOW does CAP specify busytime query/retrieval.  Using iTIP REQUEST/REPLY appears to be your response but where do I query to get the REPLYs from you, Pat and Bob?  Do I SEARCH my UNPROCESSED docs??  Ugh!  Thats really

I strongly think that that approach is the wrong one to take and that CAP should have a clearer and better mechanism for doing this.  

From the skimming of the flurry of msgs today I get the impression that dynamic data is the way we all think it should go (we just disagree about how to extend it I think).  

For CAP 1.0 we can simply say that the CS returns data is reflective of the TARGETs contents "subject to Administrative policies" and that the CS is responsible for maintaining the VFREEBUSY in the store/calendar (NOT the CUA!).  You can then build your bells/whistles features as such and thus provide the nifty features to any CAP client.  

Of course to even try this we need more votes...  Ive seen 4 so far.  Do I count you as #5 Doug?

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 0057CBF185256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 11:27:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16072 for ; Wed, 2 Apr 2003 11:27:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32G7CJM014777 for ; Wed, 2 Apr 2003 08:07:12 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32G7CiV014776 for ietf-calendar-bks; Wed, 2 Apr 2003 08:07:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32G7BJM014772 for ; Wed, 2 Apr 2003 08:07:11 -0800 (PST) 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 h32G79M4029138 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 08:07:11 -0800 Message-ID: <3E8B0AA7.5070004@Royer.com> Date: Wed, 02 Apr 2003 09:07:03 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT References: <3E8AFE99.50707@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010406020404020405010506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010406020404020405010506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > In this case, people would care, because a bot could not update the > freebusy information immediately (we don't have notifications of > changes), so there would always be a lag between adding an event and > seeing the updated VFREEBUSY. And admins would resent the performance > cost of having those bots polling all the time, so they would try to > keep that poll interval long, which would make that lag worse. > Performance would probably be better if the VFREEBUSY were being > generated in the CS. I for one would compile in my VFREEBUSY-BOT into my CS to avoid the poll problem. How the contents of the VFREEBUSY time objects are created is under dispute. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010406020404020405010506 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIxNjA3MDNaMCMGCSqGSIb3DQEJBDEWBBSl hinBBr9B7vc6+vFEEg+L7fiSgjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAq6hGcw0cVEUO nwy1VFZxZLQzWMzjAlvFpqWqgsYJNLzGAy5ceGBKyL1WC7zP5djHYKvlVl+Am8Rwtmr94KQ7 UGoLHtysbPS90+tyUjX7Ak/Y9u+tyhsXHlrNoGwxL6vIdtN/TXB6ebRfHcdlhzi+Y7zOEhSo MAZT87I8GzdCkiJ85XZfLvCEs7TbKfzWowOjfy2n3W1XErdqCqK3xWY/y4IYLDnN5719O6g3 Ymba9urZoF4r3BEJ5wkRa7McJ5mEzFUxK9gf1cKHLjPCEXyAbFmSUZUormc0eYhVMg0Mmu5U ifJwTp8pV7QgaM45tITGQCSLoWjHUikX0XurhOXaugAAAAAAAA== --------------ms010406020404020405010506-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 11:45:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17373 for ; Wed, 2 Apr 2003 11:45:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32GQ9JM015825 for ; Wed, 2 Apr 2003 08:26:10 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32GQ9aV015824 for ietf-calendar-bks; Wed, 2 Apr 2003 08:26:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32GQ8JM015818 for ; Wed, 2 Apr 2003 08:26:08 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040211303702906 for ; Wed, 02 Apr 2003 11:30:37 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 11:23:52 -0500 Message-ID: <3E8B0E98.1080601@centive.com> Date: Wed, 02 Apr 2003 11:23: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: CAP Editoral: Acronyms in Section 1 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 16:23:52.0712 (UTC) FILETIME=[3FFF8080:01C2F934] 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: > In showing CAP to someone they started to read Section 1 Introduction > and were somewhat confused by the yet undefined acronyms it used: Is it reasonable to expect someone to be able to read the CAP spec if they haven't read 2445? -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 12:46:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20360 for ; Wed, 2 Apr 2003 12:46:09 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32HFrJM018761 for ; Wed, 2 Apr 2003 09:15:53 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32HFrhU018760 for ietf-calendar-bks; Wed, 2 Apr 2003 09:15:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32HFqJM018755 for ; Wed, 2 Apr 2003 09:15:52 -0800 (PST) Received: (qmail 19918 invoked from network); 2 Apr 2003 17:15:49 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 2 Apr 2003 17:15:49 -0000 Subject: DURATION vs DTEND From: Dan Winship To: ietf-calendar@imc.org Content-Type: text/plain Message-Id: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 02 Apr 2003 12:15:33 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >From cap-10 6.1.1.10: As "DTEND" value is the first time that is excluded from a components time range, any "DURATION" value supplied by the "QUERY" property value that is exactly one second less than the "DTEND" property value MUST match the QUERY. And if the "DURATION" property value ends exactly at the computed DTEND it MUST NOT match. etc. That's wrong, right? DTSTART + DURATION == DTEND, not DTEND - 1 -- Dan From owner-ietf-calendar@mail.imc.org Wed Apr 2 13:06:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21110 for ; Wed, 2 Apr 2003 13:06:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32HoZJM019812 for ; Wed, 2 Apr 2003 09:50:35 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32HoZ9q019811 for ietf-calendar-bks; Wed, 2 Apr 2003 09:50:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32HoWJM019805 for ; Wed, 2 Apr 2003 09:50:33 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040212545910913 for ; Wed, 02 Apr 2003 12:55:00 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 12:48:15 -0500 Message-ID: <3E8B225F.7070105@centive.com> Date: Wed, 02 Apr 2003 12:48:15 -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: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> In-Reply-To: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 17:48:15.0280 (UTC) FILETIME=[09861300:01C2F940] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan Winship wrote: >>From cap-10 6.1.1.10: > > As "DTEND" value is the first time that is excluded from a components > time range, any "DURATION" value supplied by the "QUERY" property > value that is exactly one second less than the "DTEND" property value > MUST match the QUERY. And if the "DURATION" property value ends > exactly at the computed DTEND it MUST NOT match. > >etc. That's wrong, right? DTSTART + DURATION == DTEND, not DTEND - 1 > > No, the text looks right. That first clause ("...first time that is excluded...") says we're dealing with a half-open interval. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 13:31:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22162 for ; Wed, 2 Apr 2003 13:31:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IEnJM020624 for ; Wed, 2 Apr 2003 10:14:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32IEnee020623 for ietf-calendar-bks; Wed, 2 Apr 2003 10:14:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32IEmJM020619 for ; Wed, 2 Apr 2003 10:14:48 -0800 (PST) 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 h32IEkM4030174 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 10:14:49 -0800 Message-ID: <3E8B288D.4060803@Royer.com> Date: Wed, 02 Apr 2003 11:14:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020407060901020604080200" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020407060901020604080200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think it is correct. Given: DTSTART 1pm DTEND: 2pm Equals: DTSTART: 1pm DURATION: 59 minutes, 59 seconds. IF you use: DTSTART: 1pm DURATION: 60 minutes. Then that would equal: DTSTART: 1pm DTEND: 2pm + 1 second. Dan Winship wrote: >>From cap-10 6.1.1.10: > > As "DTEND" value is the first time that is excluded from a components > time range, any "DURATION" value supplied by the "QUERY" property > value that is exactly one second less than the "DTEND" property value > MUST match the QUERY. And if the "DURATION" property value ends > exactly at the computed DTEND it MUST NOT match. > > etc. That's wrong, right? DTSTART + DURATION == DTEND, not DTEND - 1 > > -- Dan -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020407060901020604080200 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIxODE0MzdaMCMGCSqGSIb3DQEJBDEWBBSD g/1Y7abyDNL7EFuhJdPxuDBb3TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAFzBxetLNZiDI EpMF1lHvealZV/84FUNH5K4umuFBBYYaaMUeZbCL8VA/DijcZNbm5lBIv8EXnPIODGc4eZJ9 rvJOTRLQR3feKHiGp+i+s21G7F5XSOehsn0+Pq9Jp474ACrETfrdESREGY7ORjpVjIiOVvQM 9P/1S6T4/0pjJr+Ee6qaIR42nEnHivYexqxmjtH2m3E37uu6SrG1894uQfsW97njpx64S6H4 PgaCrhynqq4yLeLR+ZJ/cVVVZ2Ey39cFfxJWf5D7oRi4Kch9lVbNSsLumZSdEzn/ImCi0CDD B8s6z6kISlN4GS1DNFwV01w7Epq5vPk3rOBQJjcWfgAAAAAAAA== --------------ms020407060901020604080200-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 14:07:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23425 for ; Wed, 2 Apr 2003 14:07:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IdDJM021188 for ; Wed, 2 Apr 2003 10:39:13 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32IdDm7021187 for ietf-calendar-bks; Wed, 2 Apr 2003 10:39:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32IdCJM021183 for ; Wed, 2 Apr 2003 10:39:12 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040213434031254 for ; Wed, 02 Apr 2003 13:43:40 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 13:36:56 -0500 Message-ID: <3E8B2DC8.2030604@centive.com> Date: Wed, 02 Apr 2003 13:36:56 -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: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> In-Reply-To: <3E8B288D.4060803@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 18:36:56.0530 (UTC) FILETIME=[D6B97320:01C2F946] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > DTSTART 1pm > DTEND: 2pm > > Equals: > > DTSTART: 1pm > DURATION: 59 minutes, 59 seconds. This does not make sense; you're saying that PERIOD(DTSTART, DTEND) is the half-open interval [DTSTART, DTEND), but PERIOD(DTSTART, DURATION) is the closed interval [DTSTART,DTSTART+DURATION]. I would say that PERIOD(1PM,2PM)==PERIOD(1PM, 1hr), but that 2PM is not contained in PERIOD(1PM,2PM)--i.e., that PERIOD(1PM,2PM)==[1PM,2PM). -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 14:41:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24715 for ; Wed, 2 Apr 2003 14:41:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JPvJM024093 for ; Wed, 2 Apr 2003 11:25:57 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JPvke024092 for ietf-calendar-bks; Wed, 2 Apr 2003 11:25:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32JPsJM024069 for ; Wed, 2 Apr 2003 11:25:55 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Wed, 02 Apr 2003 12:13:18 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 02 Apr 2003 12:24:58 -0700 From: "Preston Stephenson" To: Subject: TARGET clarification Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 In section CAP CREATE section, 10.1.4, there is one example of a create with two targets. To create a new component in multiple containers simply name all of the containers in the "TARGET" in the create command. Here a new "VEVENT" component is created in two TARGET components. In this example, the "VEVENT" component is one new [iTIP] "REQUEST" to be stored in two calendars. The results would be iCalendar objects that conform to the [iTIP] replies as defined in [iTIP]. This example shows two [iTIP] "VEVENT" components being created in each of the two supplied "TARGET" properties and as it contains the "METHOD" property they will be stored in the "UNPROCESSED" state: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR ... C: END:VCALENDAR The CS could send the "VREPLY" commands in separate MIME objects, one per supplied "TARGET" property value. S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR ... S: END:VCALENDAR And the second reply for the 2nd TARGET: S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR ... S: END:VCALENDAR Are the two MIME parts in one or two BEEP wrappers? I guess I'm really asking if I have to parse multiple MIME parts in one BEEP payload? I'm a little unclear what the text "The CS could send..." means? Does that simple mean, if the create is successful, the CS will a success response; and if the create is not successful, the CS will send an error response? Thanks. Preston PS Have you got the "crate" typos in the lines? S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in [1st|2nd] TARGET. Could the phrase: To create a new component in multiple containers simply name all of the containers in the "TARGET" in the create command. be writtern? To create a new component in multiple containers simply name all of the containers with a separate "TARGET" property in the create command. From owner-ietf-calendar@mail.imc.org Wed Apr 2 14:43:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24830 for ; Wed, 2 Apr 2003 14:43:15 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JFeJM022589 for ; Wed, 2 Apr 2003 11:15:40 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JFem7022588 for ietf-calendar-bks; Wed, 2 Apr 2003 11:15:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JFdJM022564 for ; Wed, 2 Apr 2003 11:15:39 -0800 (PST) Received: (qmail 23822 invoked from network); 2 Apr 2003 19:15:36 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 2 Apr 2003 19:15:36 -0000 Subject: Re: DURATION vs DTEND From: Dan Winship To: John Stracke Cc: ietf-calendar@imc.org In-Reply-To: <3E8B225F.7070105@centive.com> References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B225F.7070105@centive.com> Content-Type: text/plain Message-Id: <1049310899.17441.34.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 02 Apr 2003 14:15:21 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wed, 2003-04-02 at 12:48, John Stracke wrote: > Dan Winship wrote: > > >>From cap-10 6.1.1.10: > > > > As "DTEND" value is the first time that is excluded from a components > > time range, any "DURATION" value supplied by the "QUERY" property > > value that is exactly one second less than the "DTEND" property value > > MUST match the QUERY. And if the "DURATION" property value ends > > exactly at the computed DTEND it MUST NOT match. > > > >etc. That's wrong, right? DTSTART + DURATION == DTEND, not DTEND - 1 > > > > > No, the text looks right. That first clause ("...first time that is > excluded...") says we're dealing with a half-open interval. Yes, exactly. How many integers are there in the half-open interval [0,1)? One. So how many seconds are there in the half-open interval [12:00:00,12:00:01)? I'd say 1 again, but according to the cap spec's math, an event that starts at 12:00:00 and ends at 12:00:01 has a duration of 0 seconds. -- Dan From owner-ietf-calendar@mail.imc.org Wed Apr 2 14:58:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25766 for ; Wed, 2 Apr 2003 14:58:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JZwJM024677 for ; Wed, 2 Apr 2003 11:35:58 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JZwOn024676 for ietf-calendar-bks; Wed, 2 Apr 2003 11:35:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JZvJM024672 for ; Wed, 2 Apr 2003 11:35:57 -0800 (PST) In-Reply-To: <3E8AFE99.50707@centive.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 14:27:08 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 02:35:46 PM, Serialize complete at 04/02/2003 02:35:46 PM Content-Type: multipart/alternative; boundary="=_alternative 006A900285256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A900285256CFC_= Content-Type: text/plain; charset="US-ASCII" John replied on 04/02/2003 10:15:37 AM: > In this case, people would care, because a bot could not update the > freebusy information immediately (we don't have notifications of > changes), so there would always be a lag between adding an event and > seeing the updated VFREEBUSY. This is all a digression from the main thread so Ill just say 1 last thing on it. That all sounds like an issue w/how you built your 'Bots' then rather than an issue with CAP. After all, if you built your 'Bot' mechanism so that they got to do things BEFORE the command completed then there is NO lag. If you built it so your 'Bot' mechanism so that its asynchronous from CS/CUA actions then yes you will have some lag (and the lag depends on your internal architecture, server load, etc). However that lag should not be that bad unless you only run your 'Bot' every hour or so... Now lets refocus on the original question/issue. Check please... 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 006A900285256CFC_= Content-Type: text/html; charset="US-ASCII"
John replied on 04/02/2003 10:15:37 AM:
> In this case, people would care, because a bot could not update the
> freebusy information immediately (we don't have notifications of
> changes), so there would always be a lag between adding an event and
> seeing the updated VFREEBUSY.

This is all a digression from the main thread so Ill just say 1 last thing on it.  

That all sounds like an issue w/how you built your 'Bots' then rather than an issue with CAP.  After all, if you built your 'Bot' mechanism so that they got to do things BEFORE the command completed then there is NO lag.  If you built it so your 'Bot' mechanism so that its asynchronous from CS/CUA actions then yes you will have some lag (and the lag depends on your internal architecture, server load, etc).  However that lag should not be that bad unless you only run your 'Bot' every hour or so...
Now lets refocus on the original question/issue.  Check please...

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 006A900285256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:05:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26610 for ; Wed, 2 Apr 2003 15:05:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JnIJM025097 for ; Wed, 2 Apr 2003 11:49:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JnIPq025096 for ietf-calendar-bks; Wed, 2 Apr 2003 11:49:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JnHJM025092 for ; Wed, 2 Apr 2003 11:49:17 -0800 (PST) In-Reply-To: <3E8B03CA.4010601@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 14:38:04 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 02:49:05 PM, Serialize complete at 04/02/2003 02:49:05 PM Content-Type: multipart/alternative; boundary="=_alternative 006B901585256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B901585256CFC_= Content-Type: text/plain; charset="US-ASCII" Doug answered on 04/02/2003 10:37:46 AM: > You already know that the above is not true. Hate to burst your bubble but passing WG Last Call is not the only step in becomming an RFC. We have to pass others and if comments received are considered significant enough to warrant reworking then the draft _IS_ sent back to the WG for fixing. > The CUA can do a SEARCH > for VFREEBUSY components. So your answer to my question is that to get busytime information the CUA simply sends a: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid CMD:SEARCH TARGET:BrucesCalendar TARGET:DougsCalendar BEGIN:VQUERY QUERY:SELECT * FROM VFREEBUSY WHERE DTEND >= '20030402T080000Z' AND DTSTART <= '20030402T190000Z' END:VQUERY END:VCALENDAR That sounds different than your first reponse which was "Its like in iTIP...". Am I misunderstanding you now or is the above correct? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B901585256CFC_= Content-Type: text/html; charset="US-ASCII"
Doug answered on 04/02/2003 10:37:46 AM:
> You already know that the above is not true.

Hate to burst your bubble but passing WG Last Call is not the only step in becomming an RFC.  We have to pass others and if comments received are considered significant enough to warrant reworking then the draft _IS_ sent back to the WG for fixing.

>                                               The CUA can do a SEARCH
> for VFREEBUSY  components.

So your answer to my question is that to get busytime information the CUA simply sends a:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//someone's prodid
CMD:SEARCH
TARGET:BrucesCalendar
TARGET:DougsCalendar
BEGIN:VQUERY
QUERY:SELECT * FROM VFREEBUSY WHERE DTEND >= '20030402T080000Z' AND DTSTART <= '20030402T190000Z'
END:VQUERY
END:VCALENDAR
That sounds different than your first reponse which was "Its like in iTIP...".   Am I misunderstanding you now or is the above correct?

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

--=_alternative 006B901585256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:15:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05071 for ; Wed, 2 Apr 2003 15:15:24 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JxfJM025469 for ; Wed, 2 Apr 2003 11:59:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JxfuZ025468 for ietf-calendar-bks; Wed, 2 Apr 2003 11:59:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JxdJM025458 for ; Wed, 2 Apr 2003 11:59:40 -0800 (PST) In-Reply-To: <3E8B073D.5090604@centive.com> To: ietf-calendar@imc.org Subject: Re: iTIP Bug: VFREEBUSY REPLYs MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 14:52:30 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 02:59:27 PM, Serialize complete at 04/02/2003 02:59:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006CE27F85256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CE27F85256CFC_= Content-Type: text/plain; charset="US-ASCII" John noted on 04/02/2003 10:52:29 AM: > But the REPLY might be compiled for a wider range than was requested > (for example, if the replying CUA has VFREEBUSYs cached for each month), > and it would be useful to know the actual range it applies to. As you will note from the table text, the data MUST be in chronological order so by checking the first and last FREEBUSY property you get that info. Sounds like you'd like to reuse DTSTART/DTEND/DURATION so you dont have to scan the FREEBUSY data. This is a niceity but by no means necessary change since all the data you need is already encoded in the FREEBUSY properties. > If the > inviter asks for freebusy time for one week, and can't come up with > anything that matches, it'd be nice to know that it already has freebusy > time for a whole month, and doesn't need to request it again. Sounds like a CUA caching issue to me. See above. The restriction table clearly needs to be adjusted to be 0+ instead of 1+ so that it can properly convey back "There is nothing on Johns calendar for today". Thats in 2445, we just didnt catch it in 2446. > On the other hand, if the request was for a whole month, and the > replying CUA has VFREEBUSYs cached by week, the REPLY might contain > multiple VFREEBUSYs, and it can use the DTSTART/DTENDs to assemble them. Again this sounds like a caching issue for the receiving CUA rather than an issue in the RFCs. Otherwise you'll have to revise 2445 to have some text that says "DTSTART and DTEND (or DURATION) may be in the reply to signify the start and end range of the contained data in the VFREEBUSY". I suspect that the addition in 2446 was a result of copy/paste oversight rather than a conscious desire to provide the niceity to the recipient CUA. 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 006CE27F85256CFC_= Content-Type: text/html; charset="US-ASCII"
John noted on 04/02/2003 10:52:29 AM:
> But the REPLY might be compiled for a wider range than was requested
> (for example, if the replying CUA has VFREEBUSYs cached for each month),
> and it would be useful to know the actual range it applies to.  

As you will note from the table text, the data MUST be in chronological order so by checking the first and last FREEBUSY property you get that info.  Sounds like you'd like to reuse DTSTART/DTEND/DURATION so you dont have to scan the FREEBUSY data.  This is a niceity but by no means necessary change since all the data you need is already encoded in the FREEBUSY properties.

>                                                                  If the
> inviter asks for freebusy time for one week, and can't come up with
> anything that matches, it'd be nice to know that it already has freebusy
> time for a whole month, and doesn't need to request it again.
Sounds like a CUA caching issue to me.  See above.

The restriction table clearly needs to be adjusted to be 0+ instead of 1+ so that it can properly convey back "There is nothing on Johns calendar for today".  Thats in 2445, we just didnt catch it in 2446.

> On the other hand, if the request was for a whole month, and the
> replying CUA has VFREEBUSYs cached by week, the REPLY might contain
> multiple VFREEBUSYs, and it can use the DTSTART/DTENDs to assemble them.
Again this sounds like a caching issue for the receiving CUA rather than an issue in the RFCs.  

Otherwise you'll have to revise 2445 to have some text that says "DTSTART and DTEND (or DURATION) may be in the reply to signify the start and end range of the contained data in the VFREEBUSY".  I suspect that the addition in 2446 was a result of copy/paste oversight rather than a conscious desire to provide the niceity to the recipient CUA.

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 006CE27F85256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:16:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06238 for ; Wed, 2 Apr 2003 15:16:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JZAJM024639 for ; Wed, 2 Apr 2003 11:35:10 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JZAWq024638 for ietf-calendar-bks; Wed, 2 Apr 2003 11:35:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32JZ9JM024634 for ; Wed, 2 Apr 2003 11:35:09 -0800 (PST) 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 h32JZ7M4030753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 11:35:10 -0800 Message-ID: <3E8B3B66.1030109@Royer.com> Date: Wed, 02 Apr 2003 12:35:02 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080200070302050702090806" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080200070302050702090806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I do not understand what you mean by 'half open'. There were discussions on this list about overlapping that one second. Given two OPAQUE VEVENTS with: DTSTART:1pm DTEND:2pm and DTSTART:2pm DTEND:3pm The 2nd one can not be booked if the 1st one is OPAQUE as the 1st DTEND includes the first second of the 2nd DTSTART. So we concluded that DTEND was the 1st second after the time ended. Making the DURATION 59 minutes, 59 seconds. I think this was even prior to CAP (but maybe not). John Stracke wrote: > > Doug Royer wrote: > >> DTSTART 1pm >> DTEND: 2pm >> >> Equals: >> >> DTSTART: 1pm >> DURATION: 59 minutes, 59 seconds. > > > This does not make sense; you're saying that PERIOD(DTSTART, DTEND) is > the half-open interval [DTSTART, DTEND), but PERIOD(DTSTART, DURATION) > is the closed interval [DTSTART,DTSTART+DURATION]. > > I would say that PERIOD(1PM,2PM)==PERIOD(1PM, 1hr), but that 2PM is not > contained in PERIOD(1PM,2PM)--i.e., that PERIOD(1PM,2PM)==[1PM,2PM). > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080200070302050702090806 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIxOTM1MDJaMCMGCSqGSIb3DQEJBDEWBBTq B88saF/svNURiC4ct63Mb4UWFDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEADVCvVbeZ47lK 8CAz2Sx4ayFnraAsbOZJgOUKAsDqIu0QSq4BB+okW+7tyJmP4dU6nk2NpTkUmjglXzB08MpL Cq3IyeBJjt39qzzA7WqNWvxFoJhslyufS6sst5Wt8wHh8Al1kMcNxVNyz7F+Z57PuaEnAAoO s8ITHSKzOjn5LQsWkqbYAb3g1M1yU8JAYW78eaRbrZT7LhOEzCtxTDcNSkPl+hQchcm3I6Jy Jk5hL23lwrqsK1xMwyyz4RQz/I95PuzApgGUQg1e3YqiSKt22rKmWFw0iFwvkcMnBhCWGb5k MJ/fWHTJVxiuDSi8QdfjryIxwDSgrwmvWHClWDulYgAAAAAAAA== --------------ms080200070302050702090806-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:20:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07270 for ; Wed, 2 Apr 2003 15:20:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32K4mJM025643 for ; Wed, 2 Apr 2003 12:04:48 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32K4moG025641 for ietf-calendar-bks; Wed, 2 Apr 2003 12:04:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32K4lJM025636 for ; Wed, 2 Apr 2003 12:04:47 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h32K4lff032182; Wed, 2 Apr 2003 15:04:47 -0500 Date: Wed, 2 Apr 2003 15:04:47 -0500 Message-Id: <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" In-reply-to: <3E8B288D.4060803@Royer.com> Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This doesn't make any sense. DTEND is the non-inclusive time. DTSTART 1pm,DURATION 0s equals DTSTART 1pm,DTEND 1pm DTEND = DTSTART + DURATION Larry Date: Wed, 02 Apr 2003 11:14:37 -0700 From: Doug Royer Given: DTSTART 1pm DTEND: 2pm Equals: DTSTART: 1pm DURATION: 59 minutes, 59 seconds. IF you use: DTSTART: 1pm DURATION: 60 minutes. Then that would equal: DTSTART: 1pm DTEND: 2pm + 1 second. From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:20:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07289 for ; Wed, 2 Apr 2003 15:20:29 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JxfJM025467 for ; Wed, 2 Apr 2003 11:59:41 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Jxf97025466 for ietf-calendar-bks; Wed, 2 Apr 2003 11:59:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JxdJM025459 for ; Wed, 2 Apr 2003 11:59:40 -0800 (PST) In-Reply-To: <3E8B0E98.1080601@centive.com> To: ietf-calendar@imc.org Subject: Re: CAP Editoral: Acronyms in Section 1 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 14:59:38 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 02:59:27 PM, Serialize complete at 04/02/2003 02:59:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006D897F85256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D897F85256CFC_= Content-Type: text/plain; charset="US-ASCII" John wrote on 04/02/2003 11:23:52 AM: > Is it reasonable to expect someone to be able to read the CAP spec if > they haven't read 2445? Perhaps you can show me where in RFC 2445 we defined the term "Calendar User" and coined the acronym "CU". We did use the term "calendar store" in 2 places but A) it was not capitalized and B) we did not coin the acronym "CS". In the Abstract the first line has: The Calendar Access Protocol (CAP) is an Internet protocol described in this memo that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). but since the Abstract is only 5 sentences long and it occurs before the large TOC it was simply overlooked when the folks skipped the TOC and went to Section 1. This may be the normal layout but the tiny Abstract makes it easily overlooked, hence my 'Editorial' comment. Im not asking for a full rewrite, just pointing something out... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D897F85256CFC_= Content-Type: text/html; charset="US-ASCII"
John wrote on 04/02/2003 11:23:52 AM:
> Is it reasonable to expect someone to be able to read the CAP spec if
> they haven't read 2445?
Perhaps you can show me where in RFC 2445 we defined the term "Calendar User" and coined the acronym "CU".

We did use the term "calendar store" in 2 places but A) it was not capitalized and B) we did not coin the acronym "CS".

In the Abstract the first line has:

The Calendar Access Protocol (CAP) is an Internet protocol described in this memo that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS).

but since the Abstract is only 5 sentences long and it occurs before the large TOC it was simply overlooked when the folks skipped the TOC and went to Section 1.  This may be the normal layout but the tiny Abstract makes it easily overlooked, hence my 'Editorial' comment.  Im not asking for a full rewrite, just pointing something out...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D897F85256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:45:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08384 for ; Wed, 2 Apr 2003 15:45:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KRsJM027635 for ; Wed, 2 Apr 2003 12:27:54 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KRsGu027634 for ietf-calendar-bks; Wed, 2 Apr 2003 12:27:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32KRqJM027624 for ; Wed, 2 Apr 2003 12:27:52 -0800 (PST) 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 h32KRkM4031216 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 12:27:53 -0800 Message-ID: <3E8B47AE.408@Royer.com> Date: Wed, 02 Apr 2003 13:27:26 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040705080404030304010905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040705080404030304010905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug answered on 04/02/2003 10:37:46 AM: > > You already know that the above is not true. > > Hate to burst your bubble but passing WG Last Call is not the only step > in becomming an RFC. We have to pass others and if comments received > are considered significant enough to warrant reworking then the draft > _IS_ sent back to the WG for fixing. True but not relevant to my point - Yes you can get an put VFREEBUSY in CAP. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040705080404030304010905 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMDI3MjdaMCMGCSqGSIb3DQEJBDEWBBQy Frq5RwT66X/JaE3rLFfxAdXXVDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAsNjfJ6GQmi3Y I0IgioF/IYw9kyvck6MmSzu62Z/0hi65uEuYitcTnLF5CQW+Xl/ZpeUttlyqW49MgdiUuc6S 7k5839ktLI3OwlcbM2oe5ehcG/GHUZ5BAS8jppeF1HI0+sPvqN0ZyyPxaa9xoDJMT2AbVKph /kIFPk3AUa/YRpUj/6C0VVW8/1HKD1syI484vgjbYtWluCF0zsJh1BDfpG5x79LY6foW3jIR zHGAxeEY2rhoKBJDAB7UMW8rSscocQGWL9mOnOr9RwQh73YdNKHnIQv39x6OOiUVTk0X+h1x LZRgxfXfovpYln+s3s2koIHzNgamJtPU/JO3lw15/wAAAAAAAA== --------------ms040705080404030304010905-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:46:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08411 for ; Wed, 2 Apr 2003 15:46:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KSsJM027781 for ; Wed, 2 Apr 2003 12:28:54 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KSsRO027780 for ietf-calendar-bks; Wed, 2 Apr 2003 12:28:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32KSqJM027762 for ; Wed, 2 Apr 2003 12:28:53 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040215332202588 for ; Wed, 02 Apr 2003 15:33:22 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 15:26:38 -0500 Message-ID: <3E8B477E.5090605@centive.com> Date: Wed, 02 Apr 2003 15:26:38 -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: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> <3E8B3B66.1030109@Royer.com> In-Reply-To: <3E8B3B66.1030109@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 20:26:38.0163 (UTC) FILETIME=[29AEF230:01C2F956] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > I do not understand what you mean by 'half open'. Ah. Definitions: (a,b) is the set of numbers x such that a So we concluded that DTEND was the 1st second after the time > ended. This is not a good way of approaching the problem; it's highly prone to off-by-one errors. Plus, it doesn't leave room for expanding to subsecond resolution, should that ever be useful. Half-open intervals are the Right Thing: the DTEND is not included in the interval, so there is no overlap between [a,b) and [b,c). For a slightly more pragmatic approach: by your definition, if a user says "my opaque event starts at 1:00, and lasts for 1 hour", do you want to explain to them why they can't schedule another opaque event at 2:00? > I think this was even prior to CAP (but maybe not). It's not in RFC-2445; I searched for "duration", but there was no definition of how DTEND and DURATION relate. And, of course, 2445 is where such a definition belongs; it should not be in CAP. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:46:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08427 for ; Wed, 2 Apr 2003 15:46:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KAWJM025865 for ; Wed, 2 Apr 2003 12:10:32 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KAWfD025864 for ietf-calendar-bks; Wed, 2 Apr 2003 12:10:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32KAUJM025846 for ; Wed, 2 Apr 2003 12:10:31 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040215145122854 for ; Wed, 02 Apr 2003 15:14:51 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 15:08:07 -0500 Message-ID: <3E8B4327.1000504@centive.com> Date: Wed, 02 Apr 2003 15:08:07 -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: CAP & busytime? - not CAP reqirement - CUA-BOT References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 20:08:07.0502 (UTC) FILETIME=[93AD86E0:01C2F953] 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 04/02/2003 10:15:37 AM: > > In this case, people would care, because a bot could not update the > > freebusy information immediately (we don't have notifications of > > changes), so there would always be a lag between adding an event and > > seeing the updated VFREEBUSY. > > This is all a digression from the main thread No, it's not. The assertion has been made that having a bot would let us get away with not having the CS generate VFREEBUSYs; my point is that that is not an adequate solution. > That all sounds like an issue w/how you built your 'Bots' then rather > than an issue with CAP. After all, if you built your 'Bot' mechanism > so that they got to do things BEFORE the command completed then there > is NO lag. Uh...and how is that done? A bot generally means an application that runs as a client. What you're talking about would require notifications in CAP. If you're talking about some sort of out-of-band integration with the CS, then how is that different from having the CS build the VFREEBUSYs itself? From the CAP point of view, it's purely a matter of internal architecture. > If you built it so your 'Bot' mechanism so that its asynchronous from > CS/CUA actions then yes you will have some lag (and the lag depends on > your internal architecture, server load, etc). However that lag > should not be that bad unless you only run your 'Bot' every hour or so... Once an hour is *expensive*. Think about it: when sizing the server needed for N users, one makes assumptions on how often those users will consult their calendar. A reasonable assumption is that an average user will not check their monthly view more than once per hour. This freebusy bot is going to be at least as expensive as a monthly view, since it has to update *every* range in the user's calendar. So, with bots polling once per hour per user (which isn't really often enough), you're talking about at least doubling the load on the CS. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:53:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08683 for ; Wed, 2 Apr 2003 15:53:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KcFJM029207 for ; Wed, 2 Apr 2003 12:38:15 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KcF9R029206 for ietf-calendar-bks; Wed, 2 Apr 2003 12:38:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KcEJM029198 for ; Wed, 2 Apr 2003 12:38:14 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp7.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h32KcEpe009797; Wed, 2 Apr 2003 15:38:14 -0500 Date: Wed, 2 Apr 2003 15:38:14 -0500 Message-Id: <200304022038.h32KcEpe009797@smtp7.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" , ietf-calendar@imc.org In-reply-to: <3E8B3B66.1030109@Royer.com> Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> <3E8B3B66.1030109@Royer.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Wed, 02 Apr 2003 12:35:02 -0700 From: Doug Royer DTSTART:1pm DTEND:2pm and DTSTART:2pm DTEND:3pm The 2nd one can not be booked if the 1st one is OPAQUE as the 1st DTEND includes the first second of the 2nd DTSTART. So we concluded that DTEND was the 1st second after the time ended. Making the DURATION 59 minutes, 59 seconds. This is incorrect. Section 4.6.1 (page 53) of RFC 2445 is quite explicit: 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. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For "DTEND" is _non-inclusive_. That means the first event does not include 2pm. The second event does include 2pm, but does not include 3pm. Both events have a duration of 1H. Larry From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:53:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08707 for ; Wed, 2 Apr 2003 15:53:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32Kd0JM029317 for ; Wed, 2 Apr 2003 12:39:00 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Kd0dV029316 for ietf-calendar-bks; Wed, 2 Apr 2003 12:39:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32KcwJM029289 for ; Wed, 2 Apr 2003 12:38:58 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Wed, 02 Apr 2003 13:26:19 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 02 Apr 2003 13:38:01 -0700 From: "Preston Stephenson" To: "<" Subject: CAP plumbing Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_E1BE597B.1C7D1221" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_E1BE597B.1C7D1221 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I guess I'm trying to combine steps. I would like the capability to say: CUA: create VFREEBUSY REQUEST CS: create succeeded (Oh, by the way, here is the VFREEBUSY REPLY) If the CS doesn't support that functionality, then the CUA(s) could do the processing. Does this break CAP too much? Preston --=_E1BE597B.1C7D1221 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: 8bit
I guess I'm trying to combine steps.
I would like the capability to say:
CUA: create VFREEBUSY REQUEST
CS: create succeeded (Oh, by the way, here is the VFREEBUSY REPLY)
 
If the CS doesn't support that functionality, then the CUA(s) could do the processing.
 
Does this break CAP too much?
Preston
 
--=_E1BE597B.1C7D1221-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 15:59:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08873 for ; Wed, 2 Apr 2003 15:59:21 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KmWJM000999 for ; Wed, 2 Apr 2003 12:48:32 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KmWdK000998 for ietf-calendar-bks; Wed, 2 Apr 2003 12:48:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32KmVJM000994 for ; Wed, 2 Apr 2003 12:48:31 -0800 (PST) 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 h32KmUM4031373 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 12:48:32 -0800 Message-ID: <3E8B4C94.9020505@Royer.com> Date: Wed, 02 Apr 2003 13:48:20 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050902040301070206080406" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050902040301070206080406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > This doesn't make any sense. DTEND is the non-inclusive time. > > DTSTART 1pm,DURATION 0s > equals > DTSTART 1pm,DTEND 1pm > > DTEND = DTSTART + DURATION I am confused. You and I agree that DTEND is non-inclusive. So DTSTART 1pm, DTEND 2pm is only 59 minuets, 59 seconds in DURATION. With a DTSTART of 13:00:00 : DTEND 14:00:01 14:00:00 hours - 13:00:00 hours = 60 minutes, 0 seconds duration. DTEND 14:00:00 13:59:59 hours - 13:00:00 hours = 59 minuets, 59 seconds duration. And DTSTART == DTEND is illegal per iCal: Description: Within the "VEVENT" calendar component, this property defines the date and time by which the event ends. The value MUST be later in time than the value of the "DTSTART" property. Else duration would be (-1). --------------ms050902040301070206080406 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMDQ4MjBaMCMGCSqGSIb3DQEJBDEWBBR1 iSASlVJKFAKSJBuWNmJvaplhBDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAVPmqgXzBmrXI QbOQAcYXPsI5XP9cTxXAemdK+nTWQ66H7QyJQVa5pCcNIvm+rMggb3irTjJqb+0+h+L4pynE 0qK0pRsGraRMB9QI0/M9l7CJtiyO2xTxu5q0+z/wsBaTR6p+z9l3lRXVi22m1bhhAiklSS5E fqHyuBoS061ePOQyldTOtHLarhbmmxLR6mYFMCL7yEREK0bPwhOOJLDHdfijy1bsjtK9kI36 o6wYI4kp+U8vkU6KOlgBiQaLrGHqZI/C2VJEc9VQlIm3iuG8DDu3JV6wLdxsC/RaT6QWHhOP S5O85I4g+PIeez6EeKgX0m4QiQK4jl2EQCb2cV2nhQAAAAAAAA== --------------ms050902040301070206080406-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 16:11:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09413 for ; Wed, 2 Apr 2003 16:11:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32L0lJM002107 for ; Wed, 2 Apr 2003 13:00:47 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32L0lSx002106 for ietf-calendar-bks; Wed, 2 Apr 2003 13:00:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32L0kJM002102 for ; Wed, 2 Apr 2003 13:00:46 -0800 (PST) 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 h32L0jM4031475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 13:00:47 -0800 Message-ID: <3E8B4F77.8080502@Royer.com> Date: Wed, 02 Apr 2003 14:00:39 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> <3E8B3B66.1030109@Royer.com> <3E8B477E.5090605@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040308090701020404040909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040308090701020404040909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > >> So we concluded that DTEND was the 1st second after the time >> ended. > > This is not a good way of approaching the problem; it's highly prone to > off-by-one errors. Plus, it doesn't leave room for expanding to > subsecond resolution, should that ever be useful. Half-open intervals > are the Right Thing: the DTEND is not included in the interval, so there > is no overlap between [a,b) and [b,c). Explain what is the difference between 'So we concluded that DTEND was the 1st second after the time ended' and 'the DTEND is not included in the interval'. > For a slightly more pragmatic approach: by your definition, if a user > says "my opaque event starts at 1:00, and lasts for 1 hour", do you want > to explain to them why they can't schedule another opaque event at 2:00? So you agree with me that: DURATION = (DTEND - DTSTART) - 1 >> I think this was even prior to CAP (but maybe not). > > > It's not in RFC-2445; I searched for "duration", but there was no > definition of how DTEND and DURATION relate. And, of course, 2445 is > where such a definition belongs; it should not be in CAP. Several iCal fixes are in CAP because there is no such iCal-fixed draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040308090701020404040909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMTAwMzlaMCMGCSqGSIb3DQEJBDEWBBR1 Yua9wq12ODOblpyhxrAD82355DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEArYcHo1oNmimg ThG93gGtb+W4ELkUj9GIsMm6M3qBN4v94/SWZph6gCbs+6ja75VXFJ3jknoUrnuoGVFjC2Mi qKj9+lT+tgHMHr6Bp4oX8/ozrTlznroYQEcCYPJV+OYeK6S9OjioVvtvszCk4EIMrK9vOUNg GbP4Qn31MAu0CcC8/0OyM279QCEWkjMG60Z4t10txC49gNMKJkSbhMuqJHtAbyBE/5xUHbFK YRFtMtJMOWlxPKR1x5SzNraoVm8qs+4AMC/AHj3MBlgMHo1W2cUTfp99+QReZJoPx33zRSDW 4EHFEaqhWe+9Twxx7CuOphZdxmkVLAD25wqStV/e4QAAAAAAAA== --------------ms040308090701020404040909-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 16:15:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09588 for ; Wed, 2 Apr 2003 16:15:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32L2GJM002172 for ; Wed, 2 Apr 2003 13:02:16 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32L2GEd002171 for ietf-calendar-bks; Wed, 2 Apr 2003 13:02:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32L2DJM002164 for ; Wed, 2 Apr 2003 13:02:14 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040216064309232 for ; Wed, 02 Apr 2003 16:06:43 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 15:59:58 -0500 Message-ID: <3E8B4F4E.6080205@centive.com> Date: Wed, 02 Apr 2003 15:59:58 -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: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> <3E8B4C94.9020505@Royer.com> In-Reply-To: <3E8B4C94.9020505@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 20:59:58.0805 (UTC) FILETIME=[D228B050:01C2F95A] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > DTEND is non-inclusive. > So DTSTART 1pm, DTEND 2pm is only 59 minuets, 59 seconds > in DURATION. That does not follow. The more consistent interpretation would be that DURATION is also non-inclusive. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 16:19:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09691 for ; Wed, 2 Apr 2003 16:19:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32L72JM002401 for ; Wed, 2 Apr 2003 13:07:02 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32L72ix002400 for ietf-calendar-bks; Wed, 2 Apr 2003 13:07:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32L71JM002396 for ; Wed, 2 Apr 2003 13:07:01 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp7.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h32L72pe012152; Wed, 2 Apr 2003 16:07:02 -0500 Date: Wed, 2 Apr 2003 16:07:02 -0500 Message-Id: <200304022107.h32L72pe012152@smtp7.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" In-reply-to: <3E8B4C94.9020505@Royer.com> Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> <3E8B4C94.9020505@Royer.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Wed, 02 Apr 2003 13:48:20 -0700 From: Doug Royer Lawrence Greenfield wrote: > This doesn't make any sense. DTEND is the non-inclusive time. > > DTSTART 1pm,DURATION 0s > equals > DTSTART 1pm,DTEND 1pm > > DTEND = DTSTART + DURATION I am confused. You and I agree that DTEND is non-inclusive. So DTSTART 1pm, DTEND 2pm is only 59 minuets, 59 seconds in DURATION. DTSTART _is_ inclusive. So DTSTART 13:00:00, DTEND 13:00:01 contains exactly one second: 13:00:00. DTSTART 13:00:00, DTEND 13:00:03 contains exactly 3 seconds: 13:00:00, 13:00:01, 13:00:02. DTSTART 13:00:00, DTEND 13:01:00 contains exactly 60 seconds: 13:00:00, 13:00:01, 13:00:02, ..., 13:00:58, 13:00:59 DTSTART 13:00:00, DTEND 14:00:00 contains exactly 60 * 60 seconds, or one hour. And DTSTART == DTEND is illegal per iCal: Description: Within the "VEVENT" calendar component, this property defines the date and time by which the event ends. The value MUST be later in time than the value of the "DTSTART" property. Yes, bad example. Larry From owner-ietf-calendar@mail.imc.org Wed Apr 2 16:23:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09831 for ; Wed, 2 Apr 2003 16:23:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32LDkJM002644 for ; Wed, 2 Apr 2003 13:13:46 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32LDknS002643 for ietf-calendar-bks; Wed, 2 Apr 2003 13:13:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32LDjJM002639 for ; Wed, 2 Apr 2003 13:13:45 -0800 (PST) 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 h32LDiM4031577 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 13:13:46 -0800 Message-ID: <3E8B5282.603@Royer.com> Date: Wed, 02 Apr 2003 14:13:38 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> <3E8B3B66.1030109@Royer.com> <200304022038.h32KcEpe009797@smtp7.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010901010203050907060809" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010901010203050907060809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: r > > "DTEND" is _non-inclusive_. That means the first event does not > include 2pm. We agree. > The second event does include 2pm, but does not include > 3pm. Both events have a duration of 1H. We agree - however in the original iCal thinking, the first DID include 2pm making. And that is the change. So, perhaps the wording needs fixed up as it was trying to point out that overlap fact. And if 2pm is not included (and we agree that it is not), then the clock time for the first appointment is 13:00:00 -> 13:59:59 as 14:00 is NOT included. Making the DURATION 00:59:59 and not 1H. Original post: >>From cap-10 6.1.1.10: >> >> As "DTEND" value is the first time that is excluded from a components >> time range, any "DURATION" value supplied by the "QUERY" property >> value that is exactly one second less than the "DTEND" property value >> MUST match the QUERY. And if the "DURATION" property value ends >> exactly at the computed DTEND it MUST NOT match. >> >> etc. That's wrong, right? DTSTART + DURATION == DTEND, not DTEND - 1 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010901010203050907060809 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMTEzMzhaMCMGCSqGSIb3DQEJBDEWBBRa JEQpPG2l1JarZqUe9Amy1pOnXDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEADZ50aCuVq+YU TqUeSSj4lZVCVLj1vovBOYCtXm/7yBPmbn7tEMafmSI1XC8brlX0Tb/V62o9gOPI7FoUM2mD yIvJR58I3s+s9Be9FRJ2HdjAs/DyjDTKybRV7OZ+sdPJhzUWdAUJYM4a6R0yHtl9TAmWJ6EN 3dbPq+4OQ0X7OCQy5xefk/88TS0q3fUihAnEOWe1sg91tZa9mVrPWC4E4qb38dz6Su+xDOAv dvAi6TstQuWEBP5MTKHjeYqg9txQSo0uiat7l565Af9YmxZnXusseI4NatLtTmgBEpZ0fZw3 dqt6MeCMtMyN4DphO26S9L1EoMFIfCwYPF1CouMn+wAAAAAAAA== --------------ms010901010203050907060809-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 16:35:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10592 for ; Wed, 2 Apr 2003 16:35:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32LOBJM003063 for ; Wed, 2 Apr 2003 13:24:11 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32LOBJp003062 for ietf-calendar-bks; Wed, 2 Apr 2003 13:24:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32LO9JM003057 for ; Wed, 2 Apr 2003 13:24:09 -0800 (PST) In-Reply-To: <3E8B08C4.7060209@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Apr 2003 15:58:03 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/02/2003 04:24:13 PM, Serialize complete at 04/02/2003 04:24:13 PM Content-Type: multipart/alternative; boundary="=_alternative 0072E2BF85256CFC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072E2BF85256CFC_= Content-Type: text/plain; charset="US-ASCII" Doug fired back on 04/02/2003 10:59:00 AM: > I think that it is less likely that we in this WG can draft a document > that will reflect what every CU and vertical application will want > in the VFREEBUSY data presented. Im not interested in new drafts now. Im interested to see how something that is currently claimed to be available in CAP but I can find no prose for. When we created the CS for CAP we have an added responsiblity to factor in stuff like access rights, busytime handling, etc. We did the former. I think we've overlooked the latter. In iTIP we left generating the VFREEBUSY REPLY up to the ATTENDEEs using whatever mechanism they had tied into their MUA. However in a 'realtime' environment that CAP is targeted at we cannot just play osterich... > > That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today > > but the VFREEBUSY data on my calendar says Im > > FREEBUSY:20030402T060000Z/20030402T063000Z. This makes busytime useless > > for trying to schedule with me. > > For some resource calendars that may be valid. Only the CUA/CU and > perhaps the CS knows. Maybe the resources for that time slot > are not filled up. Huh!?!?! Exactly when would a potential user of a resource want to know the ABSOLUTE WRONG busytime information about that resource?! Hmm, let me see... Im sure LOTs of folks would love to book hotel rooms, rental cars, doctors visits, etc at times when the room, car, doctor are NOT available! Happens ever day now that I think of it. Sorry I asked... The CS knows for sure the entire contents of any given calendar within the CS and as such it has the best picture of the busytime represented by the contents therein. The CU/CUA may have a partial view of things but they are not guaranteed to be as current as the CS's view of things. For example: You may know your schedule for today but if your AA schedules a 1-on-1 w/your boss (and has Direct Book ablities) then the CS knows you are now busy but you _do not_. As such you would fail to update the VFREEBUSY data properly. Then again your could poll for new entries that someone _may_ have direct booked and then update the VFREEBUSY info (belatedly). Yeah, thats scales well... > > CAP 1.0 currently allows (in theory) the ability for a CUA to CREATE or > > modify ANY component type. This means that A) there is an implict > > burden on CUAs to maintain VFREEBUSY data to be in sync w/the calendar > > contents or B) VFREEBUSY data is an unreliable/useless mechanism in CAP. > > (A) is not completely true. It is your assertion that the VFREEBUSY time > must be 'in sync'. If busytime is NOT 'in sync' (within some reasonable window) then it is useless to anyone that would use it. Inaccurate busytime information is worse than NO busytime information because it leads to nothing but frustration and extra workflow ("Gee your busytime said you were free in the AM but not in the PM but you say you only have a 9AM meeting. If I had known I could have invited Pat as well. Now Ill have to try again."). > I could have different constraints such as blocking > out 9PM-6AM in the VFREEBUSY and never allowing any component to book > at those times. Booking is totally separate from busytime. I can always overbook (assuming the 'conflict settings' of the conflicts allow it) no matter what the busytime settings say ("I now I already have a meeting at 9AM, save this one anyway!")! Busytime merely informs the viewer of entries in the calendar; it has 0, NONE, ZIP effect on any kind of booking policy. Thats a totally separate issue. > My VFREEBUSY time and the objects in my calendar > would then never be in sync. I could insert data in my VFREEBUSY time > for a 1 week vacation and not (see previous e-mail) have X number > of OPAQUE entries in my calendar for the 1 week vacation. And I could still try to book a meeting with you then as the CS has NOTHING in it for that time that is marked as TRANSP:OPAQUE-NOCONFLICT. So what was achieved?? The much more normal convention is to put some entry on your calendar that reflects the fact your are "Busy - Unavailable". That is then reflected in your VFREEBUSY data. That way someone who have access to see your calendar will also see that you have some "Vacation!!" entry there and not assume that they can book you for something. ("Hmm, Looking at Dougs calendar I see he has all of Tuesday free but the busytime check says hes unavailable. I wonder why I cant see something then!?") I have plenty of first hand experience dealing with disjoins between calendars and busytime results so I am very confident in this being the norm rather than an exception. > (B) is your opinion. Yes it is. It also happens to be easily demonstrable that if you provide incorrect or misleading busytime information you GREATLY increase user frustration and dissatisfaction with the feature to the point that they wont use it at all! There is NO prose anywhere in CAP about how/when VFREEBUSY information is maintained and I view that a big problem in a protocol that is supposed to be a C&S protocol. By letting anyone generate VFREEBUSY data that has NO relation to the associated TARGETs contents you end up with useless or missing data! That just makes the feature unreliable and useless itself. > I agree that something must create the VFREEBUSY time > and I do not think that this WG can determine the how the data in > VFREEBUSY objects are created. I think we _could_ but think that because time is short some folks do not want to try. If noone else wants this then remove the line "It further specifies how to search for available busy time information" from Seciton 1 and ship it. In any case I see no prose ANYWHERE in CAP 1.0 that " specifies how to search for available busy time information" and thats the point Ill keep coming back to until it sinks in. CAP claims to do something that it has NOT. > And I think we disagree in our thinking > that the VFREEBUSY time and components in the calendar must be 'in sync'. If you could give me a real case where having VFREEBUSY and calendar content OUT OF SYNC is good then I would consider it. However I _constantly_ hear that users want the data to _always_ be in sync. > The VFREEBUSY time must be in sync with what the CU wants, not all > objects in the calendar. Reality check time. Putting 'phantom' data into the VFREEBUSY does not achieve anything worthwhile. It does NOT preclude someone from booking then because we have NEVER said that a CUA MUST use VFREEBUSY information as a filter for CREATEing entries. As such, even though your VFREEBUSY says you are BUSY for next week, that would not prevent me from 'overbooking' a meeting with you. If you really wanted to block next week off then more than likely create an entry that lasted all week so that noone could overbook you. Back to basics time: the VFREEBUSY represents the busytime of the TARGET calendars. If a CU wants to be unavailable then putting the proper entry on the calendar is the proper way to go. Not having calendar entries in the VFREEBUSY that are in the calendar achieves what? Nothing but frustration and anger. After all, if you cannot rely on the VFREEBUSY data, why bother checking it?? Its the job of the CUA and CS to manifest the CUs wishes in the proper way. Doing so in any other manner is not a smart idea... > I am saying that this is a topic in itself and does not need to be > in CAP. Thats your opinion. > > BTW: I dont think I saw an answer as to where my CUA would/should poll > > in order to get the iTIP VFREEBUSY REPLY. Would that be a magically > > created UNPROCESSED document in _my_ calendar that I would have to > > SEARCH for? > > We also squashed notifications (yet another draft I have written > waiting for CAP). That will allow you to not have to POLL for > anything - including VFREEBUYSY. Still no answer... Check! 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 0072E2BF85256CFC_= Content-Type: text/html; charset="US-ASCII"
Doug fired back on 04/02/2003 10:59:00 AM:
> I think that it is less likely that we in this WG can draft a document
> that will reflect what every CU and vertical application will want
> in the VFREEBUSY data presented.

Im not interested in new drafts now.  Im interested to see how something that is currently claimed to be available in CAP but I can find no prose for.

When we created the CS for CAP we have an added responsiblity to factor in stuff like access rights, busytime handling, etc.  We did the former.  I think we've overlooked the latter.

In iTIP we left generating the VFREEBUSY REPLY up to the ATTENDEEs using whatever mechanism they had tied into their MUA.  However in a 'realtime' environment that CAP is targeted at we cannot just play osterich...

> > That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today
> > but the VFREEBUSY data on my calendar says Im
> > FREEBUSY:20030402T060000Z/20030402T063000Z.  This makes busytime useless
> > for trying to schedule with me.
>
> For some resource calendars that may be valid. Only the CUA/CU and
> perhaps the CS knows. Maybe the resources for that time slot
> are not filled up.
Huh!?!?!  Exactly when would a potential user of a resource want to know the ABSOLUTE WRONG busytime information about that resource?!

Hmm, let me see...  Im sure LOTs of folks would love to book hotel rooms, rental cars, doctors visits, etc at times when the room, car, doctor are NOT available!  Happens ever day now that I think of it.  Sorry I asked...

The CS knows for sure the entire contents of any given calendar within the CS and as such it has the best picture of the busytime represented by the contents therein.  The CU/CUA may have a partial view of things but they are not guaranteed to be as current as the CS's view of things.  For example:  You may know your schedule for today but if your AA schedules a 1-on-1 w/your boss (and has Direct Book ablities) then the CS knows you are now busy but you _do not_.  As such you would fail to update the VFREEBUSY data properly.  Then again your could poll for new entries that someone _may_ have direct booked and then update the VFREEBUSY info (belatedly).  Yeah, thats scales well...

> > CAP 1.0 currently allows (in theory) the ability for a CUA to CREATE or
> > modify ANY component type.  This means that A) there is an implict
> > burden on CUAs to maintain VFREEBUSY data to be in sync w/the calendar
> > contents or B) VFREEBUSY data is an unreliable/useless mechanism in CAP.
>
> (A) is not completely true. It is your assertion that the VFREEBUSY time
> must be 'in sync'.

If busytime is NOT 'in sync' (within some reasonable window) then it is useless to anyone that would use it.  Inaccurate busytime information is worse than NO busytime information because it leads to nothing but frustration and extra workflow ("Gee your busytime said you were free in the AM but not in the PM but you say you only have a 9AM meeting.  If I had known I could have invited Pat as well.  Now Ill have to try again.").

>                      I could have different constraints such as blocking
> out 9PM-6AM in the VFREEBUSY and never allowing any component to book
> at those times.

Booking is totally separate from busytime.  

I can always overbook (assuming the 'conflict settings' of the conflicts allow it) no matter what the busytime settings say ("I now I already have a meeting at 9AM, save this one anyway!")!  Busytime merely informs the viewer of entries in the calendar; it has 0, NONE, ZIP effect on any kind of booking policy.  Thats a totally separate issue.  

>                 My VFREEBUSY time and the objects in my calendar
> would then never be in sync. I could insert data in my VFREEBUSY time
> for a 1 week vacation and not (see previous e-mail) have X number
> of OPAQUE entries in my calendar for the 1 week vacation.
And I could still try to book a meeting with you then as the CS has NOTHING in it for that time that is marked as TRANSP:OPAQUE-NOCONFLICT.  So what was achieved??

The much more normal convention is to put some entry on your calendar that reflects the fact your are "Busy - Unavailable".  That is then reflected in your VFREEBUSY data.  That way someone who have access to see your calendar will also see that you have some "Vacation!!" entry there and not assume that they can book you for something.  ("Hmm, Looking at Dougs calendar I see he has all of Tuesday free but the busytime check says hes unavailable.  I wonder why I cant see something then!?")  

I have plenty of first hand experience dealing with disjoins between calendars and busytime results so I am very confident in this being the norm rather than an exception.

> (B) is your opinion.

Yes it is.  It also happens to be easily demonstrable that if you provide incorrect or misleading busytime information you GREATLY increase user frustration and dissatisfaction with the feature to the point that they wont use it at all!

There is NO prose anywhere in CAP about how/when VFREEBUSY information is maintained and I view that a big problem in a protocol that is supposed to be a C&S protocol.  By letting anyone generate VFREEBUSY data that has NO relation to the associated TARGETs contents you end up with useless or missing data!  That just makes the feature unreliable and useless itself.

>                     I agree that something must create the VFREEBUSY time
> and I do not think that this WG can determine the how the data in
> VFREEBUSY objects are created.

I think we _could_ but think that because time is short some folks do not want to try.  If noone else wants this then remove the line "It further specifies how to search for available busy time information" from Seciton 1 and ship it.  In any case I see no prose ANYWHERE in CAP 1.0 that "specifies how to search for available busy time information" and thats the point Ill keep coming back to until it sinks in.  CAP claims to do something that it has NOT.

>                                 And I think we disagree in our thinking
> that the VFREEBUSY time and components in the calendar must be 'in sync'.
If you could give me a real case where having VFREEBUSY and calendar content OUT OF SYNC is good then I would consider it.  However I _constantly_ hear that users want the data to _always_ be in sync.

> The VFREEBUSY time must be in sync with what the CU wants, not all
> objects in the calendar.
Reality check time.  Putting 'phantom' data into the VFREEBUSY does not achieve anything worthwhile.  It does NOT preclude someone from booking then because we have NEVER said that a CUA MUST use VFREEBUSY information as a filter for CREATEing entries.  As such, even though your VFREEBUSY says you are BUSY for next week, that would not prevent me from 'overbooking' a meeting with you.  If you really wanted to block next week off then more than likely create an entry that lasted all week so that noone could overbook you.

Back to basics time: the VFREEBUSY represents the busytime of the TARGET calendars.  If a CU wants to be unavailable then putting the proper entry on the calendar is the proper way to go.  Not having calendar entries in the VFREEBUSY that are in the calendar achieves what?  Nothing but frustration and anger.  After all, if you cannot rely on the VFREEBUSY data, why bother checking it??

Its the job of the CUA and CS to manifest the CUs wishes in the proper way.  Doing so in any other manner is not a smart idea...

> I am saying that this is a topic in itself and does not need to be
> in CAP.
Thats your opinion.

> > BTW: I dont think I saw an answer as to where my CUA would/should poll
> > in order to get the iTIP VFREEBUSY REPLY.  Would that be a magically
> > created UNPROCESSED document in _my_ calendar that I would have to
> > SEARCH for?
>
> We also squashed notifications (yet another draft I have written
> waiting for CAP). That will allow you to not have to POLL for
> anything - including VFREEBUYSY.
Still no answer... Check!

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 0072E2BF85256CFC_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 16:43:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11054 for ; Wed, 2 Apr 2003 16:43:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32LOEJM003069 for ; Wed, 2 Apr 2003 13:24:14 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32LOE7p003068 for ietf-calendar-bks; Wed, 2 Apr 2003 13:24:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32LODJM003056 for ; Wed, 2 Apr 2003 13:24:13 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040216284203948 for ; Wed, 02 Apr 2003 16:28:42 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 16:21:58 -0500 Message-ID: <3E8B5476.40301@centive.com> Date: Wed, 02 Apr 2003 16:21:58 -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: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> <3E8B3B66.1030109@Royer.com> <3E8B477E.5090605@centive.com> <3E8B4F77.8080502@Royer.com> In-Reply-To: <3E8B4F77.8080502@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 21:21:58.0394 (UTC) FILETIME=[E4B1FDA0:01C2F95D] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > John Stracke wrote: > >>> So we concluded that DTEND was the 1st second after the time >>> ended. >> >> This is not a good way of approaching the problem; it's highly prone >> to off-by-one errors. Plus, it doesn't leave room for expanding to >> subsecond resolution, should that ever be useful. Half-open >> intervals are the Right Thing: the DTEND is not included in the >> interval, so there is no overlap between [a,b) and [b,c). > > Explain what is the difference between 'So we concluded that DTEND was > the 1st second after the time ended' and 'the DTEND is not included in > the interval'. The former assumes a closed interval. With a half-open interval, the DTEND is when the period ends (as it should be), but the end of the period is not contained in the period. The other difference is that the former assumes that the minimum resolution of the calendar is 1 second. That's all we support today, but we shouldn't hardwire it in if we don't have to; it should be possible for our grandchildren to write RFC-244445, in which the time values include nanoseconds, without having to work around the 1-second assumption. >> For a slightly more pragmatic approach: by your definition, if a user >> says "my opaque event starts at 1:00, and lasts for 1 hour", do you >> want to explain to them why they can't schedule another opaque event >> at 2:00? > > So you agree with me that: > > DURATION = (DTEND - DTSTART) - 1 That is absolutely not what I'm saying. I'm saying that a user will be extremely surprised to find that DURATION != DTEND-DTSTART. Clearly, DTEND=DTSTART+DURATION, so that PERIOD(DTSTART,DURATION)=PERIOD(DTSTART,DTSTART+DURATION), and both are half-open. > Several iCal fixes are in CAP because there is no such iCal-fixed draft. Maybe there should be; people should not have to read the CAP RFC to find updates to 2445. Not every iCalendar implementer is going to use CAP, after all. Remember that we can do an RFC that updates 2445 instead of obsoleting it, so that we don't have to repeat everything we're not changing. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 17:02:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11629 for ; Wed, 2 Apr 2003 17:02:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32Ll5JM004514 for ; Wed, 2 Apr 2003 13:47:05 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Ll53A004513 for ietf-calendar-bks; Wed, 2 Apr 2003 13:47:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32Ll4JM004509 for ; Wed, 2 Apr 2003 13:47:04 -0800 (PST) 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 h32Ll3M4031869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 13:47:06 -0800 Message-ID: <3E8B5A4C.2000301@Royer.com> Date: Wed, 02 Apr 2003 14:46:52 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> <3E8B4C94.9020505@Royer.com> <200304022107.h32L72pe012152@smtp7.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020103060700050606060706" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020103060700050606060706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > DTSTART _is_ inclusive. So DTSTART 13:00:00, DTEND 13:00:01 contains > exactly one second: 13:00:00. However the clock time of 13:00:01 is not included in the appointment. So the clock time for the appointment is 13:00:00 -> 13:00:00 which is a DURATION of 0 seconds. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020103060700050606060706 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMTQ2NTNaMCMGCSqGSIb3DQEJBDEWBBTK hTMeaNgGf9jIIXUV2i5I0fdtqzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAviFOUro0hNJQ 6s4C5w664JkXIPMWMqXq/d3sFO9ok8dKaaGc9RR+g/BZb8DanOtBbkxbcFns06uo6JXexfZR MnzjysjXQ+6UeJxZ+Hjue8w5C8NFp8Q3GVEff8uZIp+slQaXvGba1WosExsX+RSsdpjWaE01 X+G3GqvMKTWx2eDQ2OvM4j/m8NAlY50IbF9IFNa5sXlxnxbcD7dWW9hJSTF4FlZ4Va97vTMq gtCU6UX0MC3fTbQ0j9WA/awvgXBboiXw3QFNADe+BhsSrqoaTZ0lA0gT7eg+qpOvo+S7RAon 3gz/KSJ06g1LAhKLX4feCY1FjOAr2vWlKawcaoUeUAAAAAAAAA== --------------ms020103060700050606060706-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 17:03:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11673 for ; Wed, 2 Apr 2003 17:03:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32LnMJM004574 for ; Wed, 2 Apr 2003 13:49:22 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32LnMpv004573 for ietf-calendar-bks; Wed, 2 Apr 2003 13:49:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32LnKJM004567 for ; Wed, 2 Apr 2003 13:49:21 -0800 (PST) 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 h32LnKM4031894 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 13:49:22 -0800 Message-ID: <3E8B5ADA.4020307@Royer.com> Date: Wed, 02 Apr 2003 14:49:14 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040706040500020002040305" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040706040500020002040305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug fired back on 04/02/2003 10:59:00 AM: > > I think that it is less likely that we in this WG can draft a document > > that will reflect what every CU and vertical application will want > > in the VFREEBUSY data presented. > > Im not interested in new drafts now. Im interested to see how something > that is currently claimed to be available in CAP but I can find no prose > for. I do not follow how your point has anything to do with the paragraph that you cited. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040706040500020002040305 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMTQ5MTRaMCMGCSqGSIb3DQEJBDEWBBT1 f+ItCp+TrWY0jo9avZGpkC++tzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAFROZiByA+ku8 Fnd6juMFhCe2KtAtQXOkq/CQF9rRMDny/o5qK16Drec+ZIaBenwlW1G03x4FagdDDVNncWpc vox9HKsopT8/JCy1J92iTnr/70UNUC4SZmaUnx0vuOmOqXoVOAgE9J4VYRx9VbIn6jaywkCZ o2lgPPzEvIRtrxm6vQGNA3bHIyVva2e3oUdUZvUNQZbOhjFCu6pQ59bMn2Qi2Qxcvo5Ev7sL u/9Tkx2O8CH2qSrZ5wfR1WsxwpBDo9ZFPJ9wxVDyBImXjzNHp/wN0b7LTI2axAzVl5ZSlm28 viu/5ko6IhwXl3mBj3W39kw7DIMAPzQAVyi7dGojLQAAAAAAAA== --------------ms040706040500020002040305-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 17:24:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12282 for ; Wed, 2 Apr 2003 17:24:54 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32M6JJM005324 for ; Wed, 2 Apr 2003 14:06:19 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32M6JW5005323 for ietf-calendar-bks; Wed, 2 Apr 2003 14:06:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h32M6HJM005315 for ; Wed, 2 Apr 2003 14:06:18 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040217104622772 for ; Wed, 02 Apr 2003 17:10:46 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 17:04:03 -0500 Message-ID: <3E8B5E53.8080807@centive.com> Date: Wed, 02 Apr 2003 17:04:03 -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: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> <3E8B4C94.9020505@Royer.com> <200304022107.h32L72pe012152@smtp7.andrew.cmu.edu> <3E8B5A4C.2000301@Royer.com> In-Reply-To: <3E8B5A4C.2000301@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2003 22:04:03.0256 (UTC) FILETIME=[C5A15B80:01C2F963] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >> DTSTART _is_ inclusive. So DTSTART 13:00:00, DTEND 13:00:01 contains >> exactly one second: 13:00:00. > > However the clock time of 13:00:01 is not included in the appointment. > So the clock time for the appointment is 13:00:00 -> 13:00:00 > which is a DURATION of 0 seconds. You're still thinking in terms of closed intervals. -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 2 17:28:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12386 for ; Wed, 2 Apr 2003 17:28:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32MCVJM005647 for ; Wed, 2 Apr 2003 14:12:31 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32MCV7F005646 for ietf-calendar-bks; Wed, 2 Apr 2003 14:12:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32MCSJM005636 for ; Wed, 2 Apr 2003 14:12:28 -0800 (PST) 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 h32MCRM4032129 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 14:12:30 -0800 Message-ID: <3E8B6041.1080507@Royer.com> Date: Wed, 02 Apr 2003 15:12:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070308060605040203020003" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070308060605040203020003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > > For some resource calendars that may be valid. Only the CUA/CU and > > perhaps the CS knows. Maybe the resources for that time slot > > are not filled up. > > Huh!?!?! Exactly when would a potential user of a resource want to know > the ABSOLUTE WRONG busytime information about that resource?! Never - and it is a good thing that we agree that a CUA/CS should never report ABSOLUTE WRONG busytime information. However for resource calendars mapping components to busytime is not always 1:1. There can be BUSY time with no entries in any calendar. And for resource calendars you can have entries that do not create busy time. Think of a pool of conference rooms with similar properties. The busy time is not filled in until all of the conference rooms are booked. There are times when a there is not a 1:1 mapping between booked components and busy time. The rules of how to compute busy time vary depending on the application and user preferences (sleep time). > > > CAP 1.0 currently allows (in theory) the ability for a CUA to > CREATE or > > > modify ANY component type. This means that A) there is an implict > > > burden on CUAs to maintain VFREEBUSY data to be in sync w/the calendar > > > contents or B) VFREEBUSY data is an unreliable/useless mechanism in > CAP. > > > > (A) is not completely true. It is your assertion that the VFREEBUSY time > > must be 'in sync'. > > If busytime is NOT 'in sync' (within some reasonable window) then it is > useless to anyone that would use it. We agree - it is reasonable for them to be out of sync :-) > Inaccurate busytime information is > worse than NO busytime information because it leads to nothing but > frustration and extra workflow ("Gee your busytime said you were free in > the AM but not in the PM but you say you only have a 9AM meeting. If I > had known I could have invited Pat as well. Now Ill have to try again."). 'Inaccurate' is only relative to the correctness of busy time for the owning CU. If they compute more busy time that your application then it is not inaccurate - you simply do not know how they computed it. The same is true for resource calendars. Just because 1 of the pool of conference rooms is booked does not mean that no one can book another of the rooms at the same time. Refer to the WG discussions pre-iCal about the LA time frame. It was the last one where I saw Pete O'Leary (before he sold his company?) > > I could have different constraints such as blocking > > out 9PM-6AM in the VFREEBUSY and never allowing any component to book > > at those times. > > Booking is totally separate from busytime. We agree. They are not going to always be in sync. > I can always overbook (assuming the 'conflict settings' of the conflicts > allow it) no matter what the busytime settings say ("I now I already > have a meeting at 9AM, save this one anyway!")! Busytime merely informs > the viewer of entries in the calendar; it has 0, NONE, ZIP effect on any > kind of booking policy. Thats a totally separate issue. Which is exactly my point. How that time is computed is going to have to be flexible. > > My VFREEBUSY time and the objects in my calendar > > would then never be in sync. I could insert data in my VFREEBUSY time > > for a 1 week vacation and not (see previous e-mail) have X number > > of OPAQUE entries in my calendar for the 1 week vacation. > > And I could still try to book a meeting with you then as the CS has > NOTHING in it for that time that is marked as TRANSP:OPAQUE-NOCONFLICT. > So what was achieved?? If you or your CUA choose to ignore that that week is shown as busy time, then when I get back from vacation I would decline your METHOD:REQUEST. > The much more normal convention is to put some entry on your calendar > that reflects the fact your are "Busy - Unavailable". That is then > reflected in your VFREEBUSY data. That way someone who have access to > see your calendar will also see that you have some "Vacation!!" entry > there and not assume that they can book you for something. ("Hmm, > Looking at Dougs calendar I see he has all of Tuesday free but the > busytime check says hes unavailable. I wonder why I cant see something > then!?") Perhaps: (1) You do not have access to the other entries. (2) I did not want to make X number of entries in my calendar to each marked as vacation in order to work around my regular entries that are OPAQUE that keep me from making 1 single vacation entry. (3) I did not want to delete my regular OPAQUE entries for that week, so I just told my CUA to deposit a VFREEBUSY info my calendar showing that I am busy that week. > I have plenty of first hand experience dealing with disjoins between > calendars and busytime results so I am very confident in this being the > norm rather than an exception. I think we agree - they do not have to be in sync. > > (B) is your opinion. > > Yes it is. It also happens to be easily demonstrable that if you > provide incorrect or misleading busytime information you GREATLY > increase user frustration and dissatisfaction with the feature to the > point that they wont use it at all! It not incorrect busy time. It just not computed the same way as you compute yours. > > I agree that something must create the VFREEBUSY time > > and I do not think that this WG can determine the how the data in > > VFREEBUSY objects are created. > > I think we _could_ but think that because time is short some folks do > not want to try. If noone else wants this then remove the line "It > further specifies how to search for available busy time information" > from Seciton 1 and ship it. In any case I see no prose ANYWHERE in CAP > 1.0 that "specifies how to search for available busy time information" > and thats the point Ill keep coming back to until it sinks in. CAP > claims to do something that it has NOT. SELECT * FROM VFREEBUSY where DTSTART > something AND DTEND < something-eles. > > And I think we disagree in our thinking > > that the VFREEBUSY time and components in the calendar must be 'in sync'. > > If you could give me a real case where having VFREEBUSY and calendar > content OUT OF SYNC is good then I would consider it. However I > _constantly_ hear that users want the data to _always_ be in sync. You have given examples yourself in your email that it is valid to not always be in sync. (The one I am replying to with this message). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070308060605040203020003 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMjEyMTdaMCMGCSqGSIb3DQEJBDEWBBR2 vOJ+u8t0uFq6acdExjfRSGg2ZTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAT4EPMIZBi3Fc 2UOJaDYjYbqo+tsSmO+mpHoGZPkIbkwB7kF1QJROot3Nb1kI9aO7ayxyiA714HhRo94KbpDh SsZsbYZrbEPhy0QG7+9ZlukIoMqXRaAuITIFp3Dg2zC29/RL1BvxY050s8GvAtioAt25Nx+A wtlVRer/uMHYGis7jEo+0KvRf2wiIxmp9OdAjM9DAd0kIjysbWpxXG+hSJYhH8SdZCx5b4wf Cn2lGeaZ40N7+Tp1qTcWgCnNMlCeLzNN7yZzcyqM4a0tApeuXW+rgEV+P7efA4A9BVfz7VBN hX7H/wIt8EHQDbSKzsp+0Zy7bx5Brcf6sbuoECKgDAAAAAAAAA== --------------ms070308060605040203020003-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 17:37:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12632 for ; Wed, 2 Apr 2003 17:37:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32MHwJM005864 for ; Wed, 2 Apr 2003 14:17:58 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32MHwrE005863 for ietf-calendar-bks; Wed, 2 Apr 2003 14:17:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h32MHuJM005859 for ; Wed, 2 Apr 2003 14:17:56 -0800 (PST) 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 h32MHtM4032171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 14:17:58 -0800 Message-ID: <3E8B618E.2070507@Royer.com> Date: Wed, 02 Apr 2003 15:17:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> <3E8B3B66.1030109@Royer.com> <3E8B477E.5090605@centive.com> <3E8B4F77.8080502@Royer.com> <3E8B5476.40301@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020306090500020004050502" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020306090500020004050502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: >> >> So you agree with me that: >> >> DURATION = (DTEND - DTSTART) - 1 > > > That is absolutely not what I'm saying. I'm saying that a user will be > extremely surprised to find that DURATION != DTEND-DTSTART. The presentation and the protocol are separate issues. They do not equal and UI's need to be aware of this and make it easier for the CU/CUA to do what the user intended. (Mind reading CUA's anyone :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020306090500020004050502 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDIyMjE3NTBaMCMGCSqGSIb3DQEJBDEWBBRe V//91fGQgGJSRbubgJl+HzSRgzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAI2z6Mqnk3eHd jpb8HBxwN75FkXiKEG949YTRp7onmH4nl1/QiysEC80m3NB+eFoKB743uG982tLnNXbMDrXl bmt/kMvWGS/nPKjBafLUKvrKWg6ddA9zPKWBLp3rtuP/NgTl0pLiZdk42dbld/L5fSfOVSjF Uh70kDvvzrIfRMZMou0MyumuCTjD+AXZH2RyEihdQO0toTxaA6sGW26QNX9vYv0WLgX+Znlx /LWT3xJv5tmjR8BAD+6huTW8BwL3WU43bg75Kgf8HujGqr7ImMQIh0BXJxZzUZXJDGBNb7qv 3MKkDQSdU0vikGlyZ3GbsuBJGBsBpCEQYatsUwOhRQAAAAAAAA== --------------ms020306090500020004050502-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 17:39:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12686 for ; Wed, 2 Apr 2003 17:39:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32MOGJM006048 for ; Wed, 2 Apr 2003 14:24:16 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32MOG0T006047 for ietf-calendar-bks; Wed, 2 Apr 2003 14:24:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32MOEJM006040 for ; Wed, 2 Apr 2003 14:24:15 -0800 (PST) Received: (qmail 11177 invoked from network); 2 Apr 2003 22:24:12 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 2 Apr 2003 22:24:12 -0000 Subject: Re: DURATION vs DTEND From: Dan Winship To: "ietf-calendar@imc.org" In-Reply-To: <3E8B5A4C.2000301@Royer.com> References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> <3E8B4C94.9020505@Royer.com> <200304022107.h32L72pe012152@smtp7.andrew.cmu.edu> <3E8B5A4C.2000301@Royer.com> Content-Type: text/plain Message-Id: <1049322238.29358.6.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 02 Apr 2003 17:23:59 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wed, 2003-04-02 at 16:46, Doug Royer wrote: > > > > DTSTART _is_ inclusive. So DTSTART 13:00:00, DTEND 13:00:01 contains > > exactly one second: 13:00:00. > > However the clock time of 13:00:01 is not included in the appointment. > So the clock time for the appointment is 13:00:00 -> 13:00:00 > which is a DURATION of 0 seconds. No, just because iCalendar doesn't let you *refer* to sub-second intervals doesn't mean they don't exist. The appointment does not extend to 13:00:01, but it does include all of the time starting when the second hand hits "00", until immediately before the second hand hits "01". That's 1 second. -- Dan From owner-ietf-calendar@mail.imc.org Wed Apr 2 17:47:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13201 for ; Wed, 2 Apr 2003 17:47:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32MVkJM006227 for ; Wed, 2 Apr 2003 14:31:46 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32MVk2v006226 for ietf-calendar-bks; Wed, 2 Apr 2003 14:31:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32MViJM006217 for ; Wed, 2 Apr 2003 14:31:44 -0800 (PST) Received: (qmail 13710 invoked from network); 2 Apr 2003 22:31:41 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 2 Apr 2003 22:31:41 -0000 Subject: cap-10 section 6.1.1 CAL-QUERY Value Type From: Dan Winship To: ietf-calendar@imc.org Content-Type: text/plain Message-Id: <1049322688.29377.15.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 02 Apr 2003 17:31:29 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1. For the purpose of a query, all components should be handled as > tables, and the properties of those components, should be handled > as columns. lose the comma after "components" > 2. All VAGENDAs and CS's look like tables for the purpose of a > QUERY. And all of their properties look like columns in those > tables. This is redundant with 1 since VAGENDAs are components, and you can't search the CS itself other than by searching the VCALSTORE, which is a component. (OTOH, if you keep this section, s/VAGENDAs/"VAGENDA" components/) > 3. You CAN NOT do any cross component-type joins. And that means > you can ONLY have one component, OR one "VAGENDA" component OR > one "VCALSTORE" component in the "FROM" clause. Likewise, "OR one "VAGENDA" component OR one "VCALSTORE" component" seems redundant. > 6. The '.' is used to separate the table name (component) and column > name (property or component) when selecting a property that is > contained inside of a component that is targeted in the TARGET > property. s/when selecting a property/when selecting a property or component/ s/in the TARGET property/by the "WHERE" clause or the "TARGET" property/ (I think?) 7 has a gratuitous ":" at the end. Oh, or is that introducing the example? The examples in this section in general need to be reformatted clearly and consistently. There needs to be indenting and/or "C:"/"S:" prefixing, or something. Also, consistency as to whether the description or the "code" comes first. (eg, the "code" of the first example is back-to-back with the "code" of the second example, making it not totally obvious that they're two separate examples). > If provided as "component-name.*", then only the properties and any > contained components will be returned: would make more sense as "If the FOO is provided as "component-name.*" ..." where "FOO" is whatever the name is for that part of the SQL statement. > (d) SELECT * FROM VEVENT AFAICT, nothing specifies whether the "SELECT * FROM" form returns the surrounding BEGIN/END or not. > (g) SELECT DTSTART,UID FROM VEVENT WHERE > VTODO.SUMMERY = "Fix typo in CAP" ... > (g) Is NOT valid because it mixes VEVENT > and VTODO properties in the same VQUERY. If that's a rule, it should be explicitly stated, not just noted as part of an example. Also, should either fix the typo or note that (g) is additionally invalid because it's ungrammatical. > cap-val = cap-cols / param > / ( cap-val "," cap-val ) That's not very clean ABNF. Do we have an ABNF guru? > cap-cols = cap-col / ( cap-cols "," cap-col) > / "*" This allows "*" to appear multiple times, or with other columns. (Dunno if that's a bug.) > cap-col = comp-name > / comp-name "." cap-prop About half of the examples (including one of the ones directly above the cap-col definition) don't parse correctly unless you add / cap-prop to the definition of cap-col. I don't know if adding that allows anything else that shouldn't be allowed though. > cap-prop = ; A property that may be in the 'cap-comp' named > ; in the "SELECT" clause. presumably s/cap-comp/comp-name/, but it's still not quite right since that would allow: SELECT VALARM FROM VEVENT WHERE PARAM(VEVENT.TRIGGER,RELATED) = 'END' > 6.1.1.1 [NOT] CAL-OWNERS() There is no way in the CAL-QUERY grammar for a "NOT" to appear before "CAL-OWNERS()". The upn-filter-specific bits should probably not be in this section. > This function returns the list of "OWNER" properties for the named > calendar when used in the "SELECT" clause. There is no way in the CAL-QUERY grammar for CAL-OWNERS() to appear in the SELECT clause. > If called as 'CAL-OWNERS(cal-address)', then it is the equivalent to > the comma separated list of owners for the named calendar id. If > 'cal-address' is a CS, it returns the "CALMASTER" property. Need to take non-local calids into account: If called as 'CAL-OWNERS(cal-address)' where 'cal-address' is the CalID of a calendar on the CS, then it is equivalent to the comma-separated list of owners for that calendar. If 'cal-address' refers to the CS itself, it returns the "CALMASTER" property. If 'cal-address' points to another CS, the results are undefined. > If used in the in the "WHERE" clause it then returns true if the > currently authenticated UPN is an owner of the currently selected > object matched in the provided "TARGET" property. Remove "then" (or s/it then/then it/). Should specify that only the non-cal-address form is allowed. > 6.1.1.3 PARAM() > When used in a "SELECT" clause, it returns the entire property and > all of that properties parameters (the result is not limited to the s/properties/property's/. Also not clear what "the entire property" is referring to. Should probably be something like When used in a "SELECT" clause, it returns the entire value of each property that contains the named parameter. > When used in the "WHERE" clause, a match is true when the parameter > value is "IN" or "LIKE" compare clause according to the supplied > WHERE values. That doesn't cover non-IN/LIKE cases. (eg, "PARAM(ATTENDEE,PARTSTAT) != 'ACCEPTED'"). I think you can just say When used in the "WHERE" clause, it returns only the value of the named parameter. and readers can mentally combine that with the LIKE/IN discussion later. > If multiple named properties contain the named > parameter, then each parameter value is compared to the condition and > if any match, then the results would be true for that condition the > same as if only one had existed. It would be a lot easier to just make PARAM take a cap-prop instead of a cap-col. (At least in the WHERE case.) There should be examples using PARAM. The rest of 6.1.1. seems to be in "whatever order we thought of problems in" order, and I propose reordering the sections like so: (the numbers are their current numbers, the order is the proposed new order) > 6.1.1.11 [NOT] LIKE > 6.1.1.12 Empty vs. NULL > 6.1.1.13 [NOT] IN > 6.1.1.8 Use of single quote > 6.1.1.9 Comparing DATE and DATE-TIME values > 6.1.1.10 DTEND and DURATION > 6.1.1.14 DATE-TIME and TIME values in a WHEN clause > 6.1.1.6 Ordering of Results > 6.1.1.7 Date sorting order ie, finish off the input syntax bits first, then the semantic bits, then the output bits. > 6.1.1.11 [NOT] LIKE > > The pattern matching characters are the '%' that matches zero or more > characters, and '_' that matches exactly one character (where > character does not always mean octet). s/the '%' that/'%', which/ s/'_' that/'_', which/ > To match a '%' or '_' in the data and not have it interpreted as a > wildcard character, they MUST BE backslash escaped. That is to > search for a '%' or '_' in the string: To match a '%', '_', or '\' in the data, you must backslash escape it in the search string. > Strings compared using the "LIKE" clause MUST BE performed using case > in-sensitive comparisons when the locale allows. s/case in-sensitive/case-insensitive/ > Some property values (such as the 'recur' value type), contain commas > ... > using the IN element. This was copied from the "[NOT] IN" section, but doesn't say the right thing here. Based on the examples in 6.1.1.13, it should say: When using a "LIKE" clause with a multi-valued property or parameter, it matches if ANY of the values matches the pattern. See the examples in Section 6.1.1.13. Neither the examples nor the text answer the question of whether "parameter LIKE '%,%'" matches "property;parameter=1,2:x". (Hopefully the answer is "no".) > 6.1.1.12 Empty vs. NULL I'd rename this to "IS [NOT] NULL" for consistency with the preceding and following sections > 6.1.1.13 [NOT] IN > > This is similar to the "LIKE" clause, except it does value matching > and not string comparison matches. It's not really all that much like the LIKE clause... > c property:parameter=1,2:x One parameter, two values. > d property:parameter="1,2",3:y One parameter, one value. > e property:parameter=",":z One parameter, one value. should be ; between the property and parameter? > 6.1.1.8 Use of single quote Maybe rename to "Literals"? The text of this section is highly redundant with the comments in the query abnf and the "LIKE" section (which it anachronistically refers to as "Note 7"). > 6.1.1.9 Comparing DATE and DATE-TIME values > > When comparing "DATE-TIME" values to "DATE" values and when comparing > "DATE" values to "DATE-TIME" values, the result will be true if the > "DATE" value is on the same day as the "DATE-TIME" value. And they > are compared in UTC no matter what time zone the data may actual have > been stored in. Presumably this means "when comparing FOR EQUALITY". But what about greater than/less than? Also, it seems that the time zone of the DATE value is irrelevant, right? When comparing a "DATE" value to a "DATE-TIME" value, the "DATE-TIME" value is first converted to UTC, and then its date portion is compared to the "DATE". The time zone of the "DATE' value is irrelevant. For example: VALUE-1 VALUE-2 Compare Results 20020304 20020304T123456 VALUE-1 == VALUE-2 (in UTC-3) (in UTC-3) 20020304 20020304T003456 VALUE-1 > VALUE-2 (in UTC) (in UTC-4) 20020304T003456Z 20020205T003456 VALUE-1 > VALUE-2 (in UTC-0) (in UTC-7) I don't really understand why the last one is there since it doesn't involve DATE values, and the timezones don't affect the answer either... > When the "DATE" value or "DATE-TIME" value is not associated with a > time zone, then the CS will compare the value assuming that the no > time zone values are in the calendars default time zone. If the "DATE-TIME" value is not associated with a time zone, then the CS will use the calendar's default time zone. > When comparing "DATE" values and "DATE-TIME" values with the "LIKE" > clause Yow! OK, yes, it's neat that you can say "date LIKE '200201%'" instead of "date > '20020101' and date < '20020201'", but you can't actually use it to fill in your calendar view, since the comparison is done in UTC, so you'll be off by a few hours on the edges. So what is the point? Why would any CUA ever want to use anything like any of the given examples? Are there any current or future CUA authors who have any concrete plans for using this functionality? Looking through the archives, I see people requesting the ability to use LIKE with text fields, but not dates. Does this really serve any purpose besides making CS authors tear their hair out? > 6.1.1.10 DTEND and DURATION Based on the thread I started about this, I suggest removing the 3rd and 4th paragraphs and changing the examples to: Given a meeting room reserved with a component that contains: DTSTART:20020127T000000Z DTEND:20020127T010000Z A query containing either of the following two "WHERE" clauses would match: WHERE VEVENT.DTSTART = '20020127T000000Z' AND VEVENT.DTEND = '20020127T010000Z' WHERE VEVENT.DTSTART = '20020127T000000Z' AND VEVENT.DURATION = 'P1H' > 6.1.1.6 Ordering of Results > Date and date time values will be sorted by their equivalent value in > UTC. No matter what the returned time zone in the result set > returns. This is so that if multiple components are returned each in > a unique time zone, the results will be sorted in UTC. This does not > mean the values MUST BE converted to UTC in the data returned to the > CUA. It means the CS must do the sort in UTC. How about: Date and date-time values will be sorted as though they were all first converted to UTC, regardless of what time zone or zones the results are actually returned in. > All other values are sorted according to the locale sorting order as > specified in the command. Or the calendar locale if known, or the CS > locale if the calendar does not have any locale set. And the locale > to use for the sort is determined in that order. All other values are sorted according to the locale sorting order. If the calendar has a locale defined, that overrides the default locale of the CS, and if the command has a locale explicitly specified, that overrides the default locale of the calendar. > 6.1.1.7 Date sorting order This should really be merged together with the other Date-sorting commentary in 6.1.1.6 > If the selected component(s) do not contain a "DTSTART" property or a > "RECURRENCE-ID" property, then the order is unspecified. Since it's possible to have a mix or components with and without the properties, it might be better to say: The order in which component(s) that do not contain a "DTSTART" property or a "RECURRENCE-ID" property are returned is not specified. From owner-ietf-calendar@mail.imc.org Wed Apr 2 19:00:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17885 for ; Wed, 2 Apr 2003 19:00:12 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32NceJM010729 for ; Wed, 2 Apr 2003 15:38:40 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32NceTr010728 for ietf-calendar-bks; Wed, 2 Apr 2003 15:38:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32NccJM010721 for ; Wed, 2 Apr 2003 15:38:39 -0800 (PST) Received: (qmail 31525 invoked from network); 2 Apr 2003 23:38:33 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 2 Apr 2003 23:38:33 -0000 Subject: do the sample queries actually work? From: Dan Winship To: ietf-calendar@imc.org Content-Type: text/plain Message-Id: <1049326701.29358.53.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 02 Apr 2003 18:38:21 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There are only two examples in cap-10 of a complete response to a SEARCH command, and both of them are errors. There really need to be some example successful queries. I think most of the examples currently in the spec are actually broken given the current definitions. :-/ > If provided as "component-name.*", then only the properties and any > contained components will be returned: > > SELECT VALARM.* FROM VEVENT WHERE UID = "123" > > Will return all of the properties in each "VALARM" component > in the matching "VEVENT" component: > > TRIGGER;RELATED=END:PT5M > REPEAT:4 > ... > TRIGGER;RELATED=START:PT5M > DURATION:PT10M > ... > ... So how do I know whether the "REPEAT:4" is associated with the RELATED=END alarm or the RELATED=START alarm? Even if you assume the CS will return all of the pieces of one VALARM before any of the pieces of the next VALARM (which the spec does not seem to require), there's no way for sure to know where the dividing line between one alarm's properties and the next's is (until you get to a duplicate property). If this interpretation is right, then any query that uses "SELECT foo.*" or "SELECT foo,bar" and can match more than one component is pretty much useless. (eg, the examples in 6.1.1.15, 6.1.1.19, 6.1.1.20). If "SELECT *" also doesn't return BEGIN/END fields (and its behavior in SCOPEs and RESTRICTIONs seems to imply that it doesn't), then examples 6.1.1.17 and most of 6.1.1.18 are also useless for the same reason, and 6.1.1.16 is at best annoying (since you'd get back a mass of properties without being told if the object they came from was a VEVENT or VTODO). -- Dan From owner-ietf-calendar@mail.imc.org Wed Apr 2 19:46:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19244 for ; Wed, 2 Apr 2003 19:46:01 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h330RAJM012616 for ; Wed, 2 Apr 2003 16:27:10 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h330RAoX012615 for ietf-calendar-bks; Wed, 2 Apr 2003 16:27:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h330R8JM012606 for ; Wed, 2 Apr 2003 16:27:08 -0800 (PST) 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 h330R7M4000943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Apr 2003 16:27:11 -0800 Message-ID: <3E8B7FD5.2090501@Royer.com> Date: Wed, 02 Apr 2003 17:27:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: DURATION vs DTEND References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <200304022004.h32K4lff032182@smtp5.andrew.cmu.edu> <3E8B4C94.9020505@Royer.com> <200304022107.h32L72pe012152@smtp7.andrew.cmu.edu> <3E8B5A4C.2000301@Royer.com> <1049322238.29358.6.camel@twelve-monkeys.boston.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090907000108080700080207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090907000108080700080207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank you - I think I was in dense mode :-) I get it now. And the sort section is going away anyway in -11 per this WG request. Thanks all of you for your patience!!! Dan Winship wrote: > On Wed, 2003-04-02 at 16:46, Doug Royer wrote: > >>>DTSTART _is_ inclusive. So DTSTART 13:00:00, DTEND 13:00:01 contains >>>exactly one second: 13:00:00. >> >>However the clock time of 13:00:01 is not included in the appointment. >>So the clock time for the appointment is 13:00:00 -> 13:00:00 >>which is a DURATION of 0 seconds. > > > No, just because iCalendar doesn't let you *refer* to sub-second > intervals doesn't mean they don't exist. The appointment does not extend > to 13:00:01, but it does include all of the time starting when the > second hand hits "00", until immediately before the second hand hits > "01". That's 1 second. > > -- Dan -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090907000108080700080207 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDMwMDI3MDFaMCMGCSqGSIb3DQEJBDEWBBTE dPhyVs4y7Y1F5Rwk0NHy3GNUwDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEARZPUNyFXizwL XLiGPUxEX5yCv86Ce5r15ZYImLLWbRynOui3+OVuZBpgfBBbSN2w5EouVDP/MaKcfdsY/dmo ZH0YXmmJAFiKHgiznqN3GvT9toDKxRNFnEYNyVvpftJyWxgDziaVj/5ooQRPSs0orht4Ro+Y KPMcGzsreAYK39+gNdYWMfhdvPCmSW3YOmV1A90jJPzGj1xzSpsPXSIbx6wobiBJML64pG8a MR8p5qJ3FSVRAgz+jt7wNL+zZ6XUt5MMoZ4OaaUp5iCL6BkhReWn7UMCX2lmA/mmVWEsm/za uuHncp137kdmL3ThufvW90QAgUw+InNuiMcVBya5CQAAAAAAAA== --------------ms090907000108080700080207-- From owner-ietf-calendar@mail.imc.org Wed Apr 2 21:44:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22032 for ; Wed, 2 Apr 2003 21:44:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h332UJJM018903 for ; Wed, 2 Apr 2003 18:30:19 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h332UJJb018902 for ietf-calendar-bks; Wed, 2 Apr 2003 18:30:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h332UIJM018898 for ; Wed, 2 Apr 2003 18:30:18 -0800 (PST) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h332Xe508970; Wed, 2 Apr 2003 18:33:40 -0800 (PST) Date: Wed, 2 Apr 2003 18:33:40 -0800 (PST) Message-Id: <200304030233.h332Xe508970@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: cap-10 section 8. comments From: slh@cac.washington.edu Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (same format as previous similar msgs) ---------------------------------------- [61;3379] Conformance: This property can be specified in "VAGENDA" and ---MUST "VCALSTORE" component. Description: This property is used to indicate whether components may conflict. That is, if their expanded instances may share the same time or overlap the same time periods. If it has a value of TRUE, then conflicts are allowed. If FALSE, the no two components may ^n conflict. ---------------------------------------- [62;3433] attcounter = "ATT-COUNTER" other-params ":" cal-address CRLF ********** [ this rule does not seem to be specified in any components abnf... it would only appear (optionally) in the VCALENDAR component? ] ---------------------------------------- [62;3451] Conformance: This property can be specified in the "VAGENDA" ---MUST component. Description: This property is used to specify a fully qualified calid. Formal Definition: The property is defined by the following notation: CALID = "CALID" other-params ":" calid CRLF -----calid ***** [ this is not defined (formally) anywhere, except for possibly here... also, there seems to be a mix of using ``CALID'' and ``CalID'' in the draft (when not speaking of the "CALID" property proper). ] ---------------------------------------- [63;3488] Conformance: The property can be specified in a "VCALSTORE" ---MUST component. Description: The parameter value SHOULD BE a MAILTO URI as defined in [URL]. It MUST BE a contact URI such as a MAILTO URI and not a home ************** page or file URI that describes how to contact the calmasters. ************************************************************* [ there is some ambiguity in parsing this. the first time I read it I thought it meant it could not be a file URI (I now assume that it can be). maybe if the or-clause was moved before the and-clause? ] Formal Definition: The property is defined by the following notation: calmaster = "CALMASTER" other-params ":" uri CRLF uri = ; IANA registered uri as defined in [iCAL] ****************************************** [ if I'm running a CS I need to register my email addr? ] ---------------------------------------- [63;3521] Conformance: This property is specified in the "VREPLY" component --MUST be that is sent in response to a "GET-CAPABILITY" command. ---------------------------------------- [65;3599] Conformance: The property can be specified in a "VREPLY" component ---MUST that is sent in response to a "GET-CAPABILITY" command. ---------------------------------------- [65;3602] Description: The value is one from a list of "CAR-NONE", "CAR-MIN", or "CAR-FULL-1". If "CAR-FULL-1" is supplied then "CAR-MIN" is also available. A "CAR-MIN" implementation only supported the "DEFAULT- VCARS" property values listed in the "VCALSTORE" component and a "CAR-MIN" implementation does not support the creation or modification of "VCAR" components from the CUA. ******************************************************************** [ what does CAR-NONE mean? ] Formal Definition: The property is defined by the following notation: car-level = "CAR-LEVEL" ":" other-params : car-level-values XXXX car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1" / other-levels ) other-levels = ; Any name published in an RFC for a "CAR-LEVEL" ; property value. ******************************************************************* [ is this different from the usual iana-token? ] ---------------------------------------- [66;3647] Conformance: The property can be specified in a "VREPLY" component in ---MUST response to a "GET-CAPABILITY" command. ---------------------------------------- [66;3665] ; All of the following MUST BE supplied in any order. ; comp-list-req = "VCALSTORE" "," "VCALENDAR" "," "VTIMEZONE" "," "VREPLY", "VAGENDA", "STANDARD", "DAYLIGHT" - "," - "," - "," ; At least one MUST BE supplied. The same value ; MUST NOT occur more than once. ; comp-list-min = ( "," "VEVENT") / ( "," "VTODO") / ( "," "VJOURNAL" ) ; The same value MUST NOT occur ; more than once. ; comp-list-opt = ( "," "VFREEBUSY" ) / ( "," "VALARM" ) ( "," "VCAR" ) / ( "," "VQUERY" ) ( "," x-comp ) / ( "," iana-comp ) ----name ----name comp-list = comp-list-req 1*3comp-list-min *comp-list-opt *("," comp-list-names) comp-name ******************************** [ this is spurious text? ] ---------------------------------------- [67;3718] Conformance: The property can be specified in a "VCALSTORE" ---MUST component. ---------------------------------------- [68;3771] Description: This property is used in the "VCAR" component to specify whether the component is decreed or not. If the "DECREED" property value is "true" then the CUA will be unable to change the contents of ----TRUE the "VCAR" component and any attempt will fail with an error. ---------------------------------------- [68;3800] Conformance: This property can be specified in "VAGENDA" and ---MUST "VCALSTORE" calendar component. ---------------------------------------- [69;3812] indicate the charset of calendar. If not specified, the default is **************** [ according to 9.1 it is required or does it mean if the property value is null? and if a (text) value can be null, does it mean much for an object to be required? ] the first value in the "VCALSTORE" components "DEFAULT-CHARSET" ^' property value list. The value MUST BE an IANA registered character set as defined in [CHARREG]. In a "VCALSTORE" component it is a comma separated list of charsets supported by the CS. The first entry is the default entry for all ******************************************** newly created "VAGENDA" components. The "UTF-8" value MUST BE in the ********************************** [ if previous comment is true, then this is extraneous? or can one be created through iTIP w/o an explicit VAGENDA? ] "VCALSTORE" component "DEFAULT-CHARSET" property list. All compliant CAP implementations (CS and CUA) MUST support the "UTF-8" charset. ---------------------------------------- [69;3853] Conformance: This property can be specified in "VAGENDA" and ---MUST "VCALSTORE" components. Description: In a "VAGENDA" component, the "DEFAULT-LOCALE" property is used to indicate the locale of the calendar. The full locale SHOULD be used. The default and minimum locale is POSIX (aka the 'C' *********** [ similar comments about required/default. and would not the default be from the VCALSTORE DEFAULT-LOCALE? ] locale). ---------------------------------------- [70;3868] In a "VCALSTORE" component it is a comma separated list of locales supported by the CS. The first value in the list is the default for ********************************************** all newly created VAGENDAs. "POSIX" MUST BE in the list. ***************************** [ similar comments about required/default. ] ---------------------------------------- [70;3900] Conformance: This property may be specified once in a "VAGENDA" and ---MUST "VCALSTORE" components. Description: A multi valued property that lists the known time zones. The first is the default. Where "TZID" property values are the same as the "TZID" property as defined in [iCAL]. If in a "VCALSTORE" component it is a comma separated list of TZIDs known to the CS. The entry is used as the default TZID list for all ************************************************** newly created calendars. The list MUST contain at least "UTC". A ************************ [ similar comments about required/default. ] "VCALSTORE" components MUST have one "VTIMEZONE" component contained in it for each value in the "DEFAULT-TZID" property value. ---------------------------------------- [71;3944] DEFAULT-TZID:US/Eastern,UTC *** [ is this valid given that ``/'' is tzidprefix? ] ---------------------------------------- [71;3948] 8.14 DEFAULT-VCARS Property * [ how come this is the only one of this group whose name is pluralized? ] ---------------------------------------- [71;3960] Conformance: This property MUST BE specified in "VCALSTORE" calendar component and MUST at least specify the following values: "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and "DEFAULTOWNER". ******************************************************************** [ given this is CAR-MIN (correct?), is this correct? (going back to what does CAR-NONE mean) ] Description: This property is used in the "VCALSTORE" component to specify the "CARID" value of the "VCAR" components that MUST BE ^s copied into now "VAGENDA" components at creation time by the CS. All -e "DEFAULT-VCAR" values must have "VCARS" components stored in the ^S X "VCALSTORE". ---------------------------------------- [72;3980] def-vcars = "DEFAULT-VCARS" other-params ":" text ^ault *( "," text ) CRLF Example: The following is an example of this property: DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY, UPDATEPARTSTATUS,DEFAULTOWNER ^ [ and in general these are often missing in the folded lines (I assume the writers care about it since it is correct in other places and in the [2445] examples). ] ---------------------------------------- [73;4057] expand = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF ------------------boolean ---------------------------------------- [74;4120] Conformance: This property is specified in the "VREPLY" component --MUST be that is sent in response to a "GET-CAPABILITY" command. ---------------------------------------- [75;4160] Conformance: This property is specified in the "VREPLY" component --MUST be that is sent in response to a "GET-CAPABILITY" command. ---------------------------------------- [75;4194] Conformance: The property can be specified in the "VCALSTORE" ---MUST *********** component. ********* [ can/MUST this be in the VCALSTORE component? replace or augment text with: and in the "VREPLY" component that is sent in response to a "GET-CAPABILITY" command. ] ---------------------------------------- [76;4231] Conformance: The property can be specified in the "VCALSTORE" ---MUST *********** component. ********* [ can/MUST this be in the VCALSTORE component? replace or augment text with: and in the "VREPLY" component that is sent in response to a "GET-CAPABILITY" command. ] ---------------------------------------- [77;4272] Conformance: This property can be specified in a component. *********** [ replace with: the "VREPLY" component that is sent in response to a "GET-CAPABILITY" command. ] Description: This property is used in the in the "GET-CAPABILITY" command reply to indicated the MIME multipart types supported. A CS and CUA SHOULD support all registered MIME multipart types. Formal Definition: The property is defined by the following notation: name = "MULTIPART" other-params ":" text *( "," text) CRLF ----multipart ---------------------------------------- [77;4300] Property Parameters: Non-standard property parameters can be ^ and language specified on this property. Conformance: This property can be specified in a component. Description: This property is used in the in component to specify a localizable display name. If more than one "NAME" properties are in a component, then they MUST have unique "LANG" parameters. If the ^UAGE ---------------------------------------- [78;4316] "LANG" parameter is not supplied, then it defaults to the "VAGENDA" ^UAGE default if the component is in a "VAGENDA", or the "VCALSTORE" default if the component is stored at the "VCALSTORE" level. ---------------------------------------- [78;4345] Property Parameters: Non-standard, alternate text representation and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX language property parameters can be specified on this property. XXXXXXXX ---------------------------------------- [79;4389] Conformance: This property can be specified in "VRIGHT" components. ---MUST ---------------------------------------- [81;4491] This description is a revision of the "REQUEST-STATUS" property for VCALENDAR version 2.0. The 'statdesc' is optional and the 'extdata' may be included when 'statdesc' is not provided. [ Property Paremters: and Conformances: (at the least) statements? ] rstatus = "REQUEST-STATUS" rstatparam ":" statcode ";" *(statdesc ) ";" *(extdata) X **************************************** [ this seems to say there will always be two semicolons in the value. if statdesc and extdata have no format, is there any meaning to them being repeatable? i.e. is there any difference between the above and: statcode ";" [statdesc] ";" [extdata] ? ] rstatparam = other-params [";" languageparm] other-params ^a ---------------------------------------- [82;4544] REQUEST-STATUS:2.8; Success\, repeating VEVENT ignored. Scheduled as a single VEVENT.;RRULE:FREQ=WEEKLY;INTERVAL=2 ^ REQUEST-STATUS:4.1;Time conflict. Date/time is busy. REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: MAILTO:jsmith@example.com ^ ---------------------------------------- [82;4569] Conformance: The property can be specified in the "VREPLY" component ---MUST in response to a "GET-CAPABILITY" command. ---------------------------------------- [83;4608] Conformance: The property can be specified in the "VREPLY" component ---MUST in response to a "GET-CAPABILITY" command. ---------------------------------------- [83;4640] Conformance: The property can be specified in the "VREPLY" component ---MUST in response to a "GET-CAPABILITY" command. ---------------------------------------- [84;4683] Conformance: The property can be specified in the "VREPLY" component ---MUST in response to a "GET-CAPABILITY" command. ---------------------------------------- [85;4748] RESTRICTION:SELECT * FROM VEVENT WHERE SELF() IN ORGANIZER ^ RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN CATEGORIES ^ ---------------------------------------- [86;4806] Conformance: This property can be specified in a "VREPLY" component ---MUST in response to a "GET-CAPABILITY" command. ---------------------------------------- [87;4853] Conformance: This property can be specified in a command component. XXXXXXX ---------------------------------------- [88;4889] Purpose: This property defines whether an component is transparent or X not to busy time searches. This is a modification to [iCAL] "TRANSP" property in that it adds some values. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in a component. ^ VEVENT ---------------------------------------- From owner-ietf-calendar@mail.imc.org Thu Apr 3 10:40:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25601 for ; Thu, 3 Apr 2003 10:40:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FNjJM019424 for ; Thu, 3 Apr 2003 07:23:45 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33FNjT3019423 for ietf-calendar-bks; Thu, 3 Apr 2003 07:23:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FNiJM019417 for ; Thu, 3 Apr 2003 07:23:44 -0800 (PST) In-Reply-To: <3E8B5ADA.4020307@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 3 Apr 2003 10:18:56 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/03/2003 10:23:30 AM, Serialize complete at 04/03/2003 10:23:30 AM Content-Type: multipart/alternative; boundary="=_alternative 0053D14D85256CFD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053D14D85256CFD_= Content-Type: text/plain; charset="US-ASCII" Doug pondered on 04/02/2003 04:49:14 PM: > > > I think that it is less likely that we in this WG can draft a document > > > that will reflect what every CU and vertical application will want > > > in the VFREEBUSY data presented. > > > > Im not interested in new drafts now. Im interested to see how something > > that is currently claimed to be available in CAP but I can find no prose > > for. > > I do not follow how your point has anything to do with the paragraph > that you cited. You said that the WG "can draft a document" and thats NOT CAP so it would have to be a new draft. I dont want to see a new draft, I want to see this working/fixed in CAP. 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 0053D14D85256CFD_= Content-Type: text/html; charset="US-ASCII"
Doug pondered on 04/02/2003 04:49:14 PM:
> >  > I think that it is less likely that we in this WG can draft a document
> >  > that will reflect what every CU and vertical application will want
> >  > in the VFREEBUSY data presented.
> >
> > Im not interested in new drafts now.  Im interested to see how something
> > that is currently claimed to be available in CAP but I can find no prose
> > for.
>
> I do not follow how your point has anything to do with the paragraph
> that you cited.
You said that the WG "can draft a document" and thats NOT CAP so it would have to be a new draft.  I dont want to see a new draft, I want to see this working/fixed in CAP.

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 0053D14D85256CFD_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 3 11:12:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27530 for ; Thu, 3 Apr 2003 11:12:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FtdJM023002 for ; Thu, 3 Apr 2003 07:55:39 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33Ftdo8023001 for ietf-calendar-bks; Thu, 3 Apr 2003 07:55:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33FtcJM022994 for ; Thu, 3 Apr 2003 07:55:39 -0800 (PST) To: ietf-calendar@imc.org Subject: Fw: CAP & busytime? - not CAP reqirement - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V65_M1_03242003NP March 24, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Thu, 3 Apr 2003 10:49:12 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/03/2003 10:55:39 AM, Serialize complete at 04/03/2003 10:55:39 AM Content-Type: multipart/alternative; boundary="=_alternative 0056BDC285256CFD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056BDC285256CFD_= Content-Type: text/plain; charset="US-ASCII" 6 Tom Ransdell ----- Forwarded by Robert Ransdell/Westford/IBM on 04/03/2003 10:46 AM ----- "Preston Stephenson" Sent by: owner-ietf-calendar@mail.imc.org 04/02/2003 08:06 AM To "<" cc Subject RE: CAP & busytime? - not CAP reqirement - CUA-BOT 5 Preston >>> "Paul B. Hill" 4/1/2003 4:04:02 PM >>> OK, we're up to 4. Keep those "votes" coming :) -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Dan Winship Sent: Tuesday, April 01, 2003 4:58 PM To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT On Tue, 2003-04-01 at 14:58, Doug Royer wrote: > Bruce_Kahn@notesdev.ibm.com wrote: > > > > The only reasonble source for keeping the VFREEBUSY accurate is to have > > it done by the CS as changes are made to the calendar. _Assuming_ that > > an unspecified "Bot" mechanism is the way that it should/would/MAY be > > done is NOT sufficient here if we want that key functionality in CAP. > > CAP 1.0 needs to provide that basic functionality in it or we severly > > risk loosing user adoption. > > Need told me and Pat repeated that we can not add features to CAP > unless 20 people on this list insist tht it must be done. Well, I agree with Bruce, so there's 2... -- Dan --=_alternative 0056BDC285256CFD_= Content-Type: text/html; charset="US-ASCII"
6
Tom Ransdell

----- Forwarded by Robert Ransdell/Westford/IBM on 04/03/2003 10:46 AM -----
"Preston Stephenson" <PStephenson@gw.novell.com>
Sent by: owner-ietf-calendar@mail.imc.org

04/02/2003 08:06 AM

To
"<"
cc
Subject
RE: CAP & busytime? - not CAP reqirement - CUA-BOT





5
Preston

>>> "Paul B. Hill" <pbh@MIT.EDU> 4/1/2003 4:04:02 PM >>>

OK, we're up to 4. Keep those "votes" coming :)

-----Original Message-----
From: owner-ietf-calendar@mail.imc.org
[mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Dan Winship
Sent: Tuesday, April 01, 2003 4:58 PM
To: ietf-calendar@imc.org
Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT



On Tue, 2003-04-01 at 14:58, Doug Royer wrote:
> Bruce_Kahn@notesdev.ibm.com wrote:
>
>
> > The only reasonble source for keeping the VFREEBUSY accurate is to have
> > it done by the CS as changes are made to the calendar.  _Assuming_ that
> > an unspecified "Bot" mechanism  is the way that it should/would/MAY be
> > done is NOT sufficient here if we want that key functionality in CAP.
> >  CAP 1.0 needs to provide that basic functionality in it or we severly
> > risk loosing user adoption.
>
> Need told me and Pat repeated that we can not add features to CAP
> unless 20 people on this list insist tht it must be done.

Well, I agree with Bruce, so there's 2...

-- Dan

 --=_alternative 0056BDC285256CFD_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 3 11:45:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29004 for ; Thu, 3 Apr 2003 11:45:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33GSQJM026370 for ; Thu, 3 Apr 2003 08:28:26 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33GSQ3R026368 for ietf-calendar-bks; Thu, 3 Apr 2003 08:28:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33GSPJM026361 for ; Thu, 3 Apr 2003 08:28:25 -0800 (PST) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h33GSKg05258 for ; Thu, 3 Apr 2003 08:28:20 -0800 (PST) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail1.oracle.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h33GSJA05220 for ; Thu, 3 Apr 2003 08:28:19 -0800 (PST) Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h33GSBI06503 for ; Thu, 3 Apr 2003 09:28:15 -0700 (MST) Received: from rgmum6.us.oracle.com (rgmum6.us.oracle.com [138.1.191.27]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h33GRwi05792 for ; Thu, 3 Apr 2003 09:28:00 -0700 (MST) Received: from dhcp-ca-mississauga-144-23-213-75.ca.oracle.com by rgmum7.us.oracle.com with ESMTP id 76303541049387187; Thu, 03 Apr 2003 11:26:27 -0500 Message-Id: <5.1.0.14.0.20030403111559.0602f5a8@rgmamerimap.oraclecorp.com> X-Sender: alan.davies@rgmamerimap.oraclecorp.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 11:29:01 -0500 To: ietf-calendar@imc.org, "ietf-calendar@imc.org" From: Alan Davies Subject: Re: DURATION vs DTEND In-Reply-To: <3E8B3B66.1030109@Royer.com> References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:35 PM 2003-04-02, Doug Royer wrote: >I do not understand what you mean by 'half open'. This is a standard mathematical term, being correctly applied to clarify the problem. A quick web search will provide the definition. >The 2nd one can not be booked if the 1st one is OPAQUE >as the 1st DTEND includes the first second of the 2nd DTSTART. >So we concluded that DTEND was the 1st second after the time >ended. Making the DURATION 59 minutes, 59 seconds. But the duration has to be 60 minutes. As someone else pointed out, an event that starts at 00:00:00 and ends at 00:00:01 has duration 1 minute, not zero minutes. It should just be stated that for the purposes of calculating conflicts the interval is considered to be half-open, with the DTEND not included in the set. Much clearer than hacking the duration. >>This does not make sense; you're saying that PERIOD(DTSTART, DTEND) is >>the half-open interval [DTSTART, DTEND), but PERIOD(DTSTART, DURATION) is >>the closed interval [DTSTART,DTSTART+DURATION]. >>I would say that PERIOD(1PM,2PM)==PERIOD(1PM, 1hr), but that 2PM is not >>contained in PERIOD(1PM,2PM)--i.e., that PERIOD(1PM,2PM)==[1PM,2PM). For Doug's benefit: The square brackets define whether or not the endpoints are included in the interval. [1pm, 2pm] defines that 1pm and 2pm are included, (1pm, 2pm) implies that neither is. I don't have a copy of ISO-8601 to hand, but I seemed to remember that it agreed with our duration calculations, not Doug's, which will just cause confusion and error. --Alan From owner-ietf-calendar@mail.imc.org Thu Apr 3 14:07:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07414 for ; Thu, 3 Apr 2003 14:07:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33IrPJM003573 for ; Thu, 3 Apr 2003 10:53:25 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33IrOb6003572 for ietf-calendar-bks; Thu, 3 Apr 2003 10:53:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33IrNJM003568 for ; Thu, 3 Apr 2003 10:53:23 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.8/8.12.3.Beta2) with ESMTP id h33IrO6s018603; Thu, 3 Apr 2003 13:53:24 -0500 Date: Thu, 3 Apr 2003 13:53:24 -0500 Message-Id: <200304031853.h33IrO6s018603@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: ietf-calendar@imc.org In-reply-to: Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: "Paul B. Hill" Date: Tue, 1 Apr 2003 18:04:02 -0500 OK, we're up to 4. Keep those "votes" coming :) At the recent IETF I was completely stunned that CAP was designed as an access to an iCalendar store for clients to do their own iTIP processing, and not as an access protocol to a calendaring server. I believe it should synthesize freebusy components---so another vote in favor. I believe that we'll hit this same disconnect on "how do I invite someone to a meeting". (Do I have to upload one component? Many components?) Larry From owner-ietf-calendar@mail.imc.org Thu Apr 3 15:21:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11635 for ; Thu, 3 Apr 2003 15:21:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33K8tJM007976 for ; Thu, 3 Apr 2003 12:08:55 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33K8tB2007975 for ietf-calendar-bks; Thu, 3 Apr 2003 12:08:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33K8rJM007971 for ; Thu, 3 Apr 2003 12:08:53 -0800 (PST) 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 h33K8oM4009829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Apr 2003 12:08:55 -0800 Message-ID: <3E8C94CC.7010105@Royer.com> Date: Thu, 03 Apr 2003 13:08:44 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT References: <200304031853.h33IrO6s018603@smtp6.andrew.cmu.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030208020802080906040907" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030208020802080906040907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > I believe that we'll hit this same disconnect on "how do I invite > someone to a meeting". (Do I have to upload one component? Many > components?) You deposit a iTIP request in the target CUs mailbox. When the target CU/CUA accesses their calendar, they reply. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030208020802080906040907 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDMyMDA4NDVaMCMGCSqGSIb3DQEJBDEWBBRd iOKIsPbxRkoiIQZ5etyfe9zL5jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEANvz/yKsqbxnX ZP8LILtsjIKTxC59wUv4M6Ob2RVxjwk3AUyORtWWOC9TaDY9Mde8Wn5VrHg8St7aSZezMgwE o1MQYtGj0/U4xmwK0FCrNCrhqiU2LLzIe8AHWECRAsVjPU41tiPeG1GcJWhUoUa4y0/wiWoT a1Li0XUogafWX2VO6XLAiYtIZjM3H+F3yXcXH+GaAqBStRWQ83Jqls0D1CbThRBFwzr8dg0A QvAkrdLT8vplYMN9rcfpD7wN1SmjW6lzI1a+MssrA9MU6uuZw0sR88mxIsXcyqrXaLDi1Yfu j3h2Vt+rQkk+JcZzfg9zDtKZM1EWTVnR1MRM2WXiyAAAAAAAAA== --------------ms030208020802080906040907-- From owner-ietf-calendar@mail.imc.org Thu Apr 3 15:39:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12695 for ; Thu, 3 Apr 2003 15:39:31 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33KNjJM008487 for ; Thu, 3 Apr 2003 12:23:45 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33KNjBm008486 for ietf-calendar-bks; Thu, 3 Apr 2003 12:23:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33KNhJM008482 for ; Thu, 3 Apr 2003 12:23:43 -0800 (PST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.12.9/8.12.6) with ESMTP id h33KLWeE012180 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 3 Apr 2003 15:21:32 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.9/8.12.6) with ESMTP id h33KLUHD027249; Thu, 3 Apr 2003 15:21:31 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.9/8.12.8/Submit) id h33KLTJC027246; Thu, 3 Apr 2003 15:21:29 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.38857.244028.129702@grandcentral.cs.columbia.edu> Date: Thu, 3 Apr 2003 15:21:29 -0500 To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: DURATION vs DTEND In-Reply-To: <3E8B5476.40301@centive.com> References: <1049303733.4759.213.camel@twelve-monkeys.boston.ximian.com> <3E8B288D.4060803@Royer.com> <3E8B2DC8.2030604@centive.com> <3E8B3B66.1030109@Royer.com> <3E8B477E.5090605@centive.com> <3E8B4F77.8080502@Royer.com> <3E8B5476.40301@centive.com> X-Mailer: VM 6.98 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, April 2 2003, "John Stracke" wrote to "ietf-calendar@imc.org" saying: > > Several iCal fixes are in CAP because there is no such iCal-fixed draft. > > Maybe there should be; people should not have to read the CAP RFC to > find updates to 2445. Not every iCalendar implementer is going to use > CAP, after all. > > Remember that we can do an RFC that updates 2445 instead of obsoleting > it, so that we don't have to repeat everything we're not changing. I'd be in favor of this; there are a number of ambiguities and under-specified areas in 2445's time handling, which I discovered in the process of adapting and implementing it for CPL. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Thu Apr 3 16:44:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15700 for ; Thu, 3 Apr 2003 16:44:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33LPgJM015022 for ; Thu, 3 Apr 2003 13:25:42 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33LPgQI015021 for ietf-calendar-bks; Thu, 3 Apr 2003 13:25:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33LPfJM015013 for ; Thu, 3 Apr 2003 13:25:41 -0800 (PST) In-Reply-To: <3E8B6041.1080507@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP & busytime? - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 3 Apr 2003 16:23:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/03/2003 04:25:26 PM, Serialize complete at 04/03/2003 04:25:26 PM Content-Type: multipart/alternative; boundary="=_alternative 007528D985256CFD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007528D985256CFD_= Content-Type: text/plain; charset="US-ASCII" This has gotten somewhat long and a bit off the base topic. Ill try to conclude this digression and get back to the base topic! Doug responsed on 04/02/2003 05:12:17 PM: > > > For some resource calendars that may be valid. Only the CUA/CU and > > > perhaps the CS knows. Maybe the resources for that time slot > > > are not filled up. > > > > Huh!?!?! Exactly when would a potential user of a resource want to know > > the ABSOLUTE WRONG busytime information about that resource?! > > Never - and it is a good thing that we agree that a CUA/CS should > never report ABSOLUTE WRONG busytime information. Goodness that we do agree (and I suspect we agree on other points too). However I strongly think that allowing/expecting the CUAs to do VFREEBUSY creation/maintenance (as appears to be the implicit expectations now) is VERY BAD and should be prevented. I expect that you would also agree to this in concept but maybe not in how its achieved (or maybe not 100% entirely). > However for resource calendars mapping components to busytime > is not always 1:1. There can be BUSY time with no entries in any > calendar. Sounds like you are taking about profilable 'work hours' or 'available hours' so that folks know "When is Doug available for meetings?" or "When is Room 1 'accessible'?". More nifty features we've had in Notes for years now. While I like that concept I do not expect it to be in CAP 1.0. For CAP 1.0 I think that having VFREEBUSYs reflect just the calendar contents is a good first step. Adding stuff like this post-CAP 1.0 is the way to go I think.... > And for resource calendars you can have entries that > do not create busy time. Think of a pool of conference rooms > with similar properties. "Pooling" is like "group calendars" and NOT something we are building in CAP 1.0. Not a worthwhile example to use now... > The busy time is not filled in until > all of the conference rooms are booked. Ahh, I see now. Rolling up the busytime of several rooms into 1 'master' busytime entry is something that I agree that was quashed in 1999 by the WG. In your view, when building a busytime roll-up system the busytime may not reflect just the contents of a calendar because it may be rolled up from others instead (or in addition?). In any case, this is NOT something Im concerned with and I think is a confusing factor in this discussion. Each separate room is busy if its booked and as such MUST be reflected in a busytime lookup for that room if checked directly. > The rules of how to compute busy time vary depending on the > application and user preferences (sleep time). Not really. If there is an entry on the calendar then its should be immediately reflected in the busytime data for that calendar. The only reason for it to NOT appear that I can think of is that there may be a slight lag in creating the entry and it actually showing up in busytime (ie: a couple seconds delay as its processed and flushed to disk). User preferences on when to compute busytime have NO input into the matter in a real time environment. What user really wants to "Update my busytime 1 hour after I add any new entries."? I get calls about "This morning I put an appointment on my calendar for 3PM on Tuesday but when Sue checks my busytime it appears as if Im free. Why?". I NEVER get calls "I put 2 appointments on my calendar this just now but I dont want them to show up in busytime until tonight. How do I do this?". > > If busytime is NOT 'in sync' (within some reasonable window) then it is > > useless to anyone that would use it. > > We agree - it is reasonable for them to be out of sync :-) More goodness... > > Inaccurate busytime information is > > worse than NO busytime information because it leads to nothing but > > frustration and extra workflow ("Gee your busytime said you were free in > > the AM but not in the PM but you say you only have a 9AM meeting. If I > > had known I could have invited Pat as well. Now Ill have to try again."). > > 'Inaccurate' is only relative to the correctness of busy time for the > owning CU. If they compute more busy time that your application then > it is not inaccurate - you simply do not know how they computed it. I think I now how to do busytime; Im the guy responsible for it in Lotus Notes and have been for since nearly the initial release of it Notes. Correctness is relative to the calendars contents, not the CUs opinion of how busytime should look. If CUs want to achieve something then the CUA simply constructs the proper calendar entry and it gets reflected in busytime. To 'undo' the effect they change or remove the entry. Trying to do manual maintenance of busytime of 'non-calendar entires' on an ad-hoc basis and NOT basing it on calendar data is too error prone to be of any good. > The same is true for resource calendars. Just because 1 of the pool > of conference rooms [Snip] Bringning up pooling or calendar / busytime roll-up is a digression from the base issue I started with and has already been quashed. Lets not try to use it now in resolving my questions please. > > > > I could have different constraints such as blocking > > > out 9PM-6AM in the VFREEBUSY and never allowing any component to book > > > at those times. > > > > Booking is totally separate from busytime. > > We agree. They are not going to always be in sync. My point was that the ability to book an entry is a completely separate issue from "Is Doug free @ 7PM EST for a meeting?". I may see you are busy from 6PM thru 9AM but I may still be able to CREATE a meeting invitation for that time. Busytime has no policy impact on entry creation. That is NOT to say that once booked for 7PM - 8PM EST your busytime is NOT reflective of the new entry! For CAP 1.0 Im NOT trying to build the most robust busytime system with tons of cool features. Its too close to ship date. Im trying to make sure that I can do the most elementary busytime lookups in CAP and be somewhat secure in the results returned are accurate of the calendars current status. > > I can always overbook (assuming the 'conflict settings' of the conflicts > > allow it) no matter what the busytime settings say ("I now I already > > have a meeting at 9AM, save this one anyway!")! Busytime merely informs > > the viewer of entries in the calendar; it has 0, NONE, ZIP effect on any > > kind of booking policy. Thats a totally separate issue. > > Which is exactly my point. How that time is computed is going to have > to be flexible. Not sure I follow here. You agree that busytime is informative and has no effect on the booking policy of the user. I assume that you also agree then that once a new entry is booked that it MUST be reflected in a subsequent busytime lookup. I for one think that the CS is the place to do that maintenance, NOT the CUA. I also think that this needs to be in CAP 1.0 for busytime to be even remotely useable 'out of the gates'. Would you agree? > > > My VFREEBUSY time and the objects in my calendar > > > would then never be in sync. I could insert data in my VFREEBUSY time > > > for a 1 week vacation and not (see previous e-mail) have X number > > > of OPAQUE entries in my calendar for the 1 week vacation. > > > > And I could still try to book a meeting with you then as the CS has > > NOTHING in it for that time that is marked as TRANSP:OPAQUE-NOCONFLICT. > > So what was achieved?? > > If you or your CUA choose to ignore that that week is shown as > busy time, then when I get back from vacation I would decline your > METHOD:REQUEST. Whats there for me or my CUA to ignore? There has been NO change proposed to fbtypeparam to include "no conflict" as a 'type' of FREEBUSY. In addition new "no conflict" types are for CAPs use so that when someone trys to overbook they are prevented. It sounds as if you are implicitly expecting that all attempts at workflow are somewhat controlled by busytime results ("You cannot meet with Pat @ 3PM, she has an entry that does not allow you to overbook!"). I think this is the wrong approach to take in using busytime. Busytime is informative only. It SHOULD be accurate but it SHOULD NOT prevent you from inviting Pat to that meeting. She may see your REQUEST, decide to try and call in and allow herself to be overbooked (its HER choice). She may see it and COUNTER you to a better time. The "no conflict" control should only be enforced by the CS and the calendar CU has the final arbitration in allowing stuff like conflicts, etc. Busytime does NOT. In any case we have greatly digressed from my original question and Im still looking for the answer: How do I get busytime information from other users via CAP? (The followon question seems to be Who is responsible for keeping the busytime information updated and when?) > (1) You do not have access to the other entries. I dont need access to the other entries for the CS to see that they are "no conflict" and thus prevent my booking a conflict. Only the CS needs that access so it can reject the CREATE. > (2) I did not want to make X number of entries in my calendar to > each marked as vacation in order to work around my regular > entries that are OPAQUE that keep me from making 1 single > vacation entry. You as the CUA have the final say so in allowing conflicts to your own calendar. As such you should be able to create any kinds of entries you like whenver you want. Any other design is fundamentally flawed. > (3) I did not want to delete my regular OPAQUE entries for that > week, so I just told my CUA to deposit a VFREEBUSY info > my calendar showing that I am busy that week. See #2... > > > I have plenty of first hand experience dealing with disjoins between > > calendars and busytime results so I am very confident in this being the > > norm rather than an exception. > > I think we agree - they do not have to be in sync. Still more goodness... > > Yes it is. It also happens to be easily demonstrable that if you > > provide incorrect or misleading busytime information you GREATLY > > increase user frustration and dissatisfaction with the feature to the > > point that they wont use it at all! > > It not incorrect busy time. It just not computed the same way > as you compute yours. It boils down to who maintains the busytime then. I contend that only the CS can consitantly and accurately represent the busytime of a calendar within it and that a CUA may be able to but not in consistant and accurate manner without becoming overly burdensome. If the design of CAP is such that its indeterminate who is to maintain the busytime info then I think its a fundamental flaw in CAP. > SELECT * FROM VFREEBUSY where DTSTART > something AND DTEND < something-eles. Hmm, 2 problems with this: 1: Thats different from your original answer of "its the same as in iTIP". Under that mode the CUA would CREATE a VFREEBUSY REQUEST and then have to poll _someplace_ TBD for the VFREEBUSY REPLY. Im not sure which is how you think CAP specifies it... 2: VFREEBUSYs use DTSTART / DTEND to delimit the bounds for the contained busytime information. Unless you build some better selection criteria OR you coerce the DTSTART / DTEND pairs to be similar in duration your SEARCH may not find VFREEBUSYs that it should. For example, if the VFREEBUSY info within the CS is stored using day increments (ie: DTSTART:20030402 / DTEND:20030402 for yesterday, DTSTART:20030403 / DTEND:20030403 for today, etc) but your SEARCH criteria is simply for "When is Doug free this AM" (ie: DTSTART:20030403T120000Z / DTEND:20030403T170000Z) then NO VFREEBUSYs would match the SEARCHs' WHERE clause and NOTHING would get returned because the DTEND of the SELECT is _ before_ the DTEND of the VFREBUSY for today! The ONLY way to use the kind of SEARCH you suggest is to search for a matching time slice and then ignore what I dont need. For example, I may want to know "When is Doug free this AM" but my SEARCH would have know to use "WHERE DTSTART >= 20030403 AND DTEND <= 20030404" and then just ignore all the extra data it gets back. This of course means that the CUA would have to know the granularity of the VFREEBUSY data its searching AND that the potential waste of bandwidth with the extra data is a necessary evil... > You have given examples yourself in your email that it is valid > to not always be in sync. (The one I am replying to with this > message). Having a small window where they are not in sync is acceptable (ie: the time it takes to process it and save the 'cache' info to disk). Thats the ONLY time it wont be in sync that Ive ever mentioned as not evil! Yesterday, Doug claimed that agregious discrepancies were ok: > That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today > but the VFREEBUSY data on my calendar says Im > FREEBUSY:20030402T060000Z/20030402T063000Z. This makes busytime useless > for trying to schedule with me. For some resource calendars that may be valid. but I have yet to hear any validation of this claim. When is having data that does NOT represent the calendars contents or even blatently misrepesents it a 'valid' case?!? Busytime should always accurately reflect the status of the calendar based on its contents! And still I dont see where in CAP I overlooked where it "specifies how to search for available busy time information"... Maybe I need some glasses. Waiter!! 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 007528D985256CFD_= Content-Type: text/html; charset="US-ASCII"
<WARNING>
This has gotten somewhat long and a bit off the base topic.  Ill try to conclude this digression and get back to the base topic!
</WARNING>

Doug responsed on 04/02/2003 05:12:17 PM:
> >  > For some resource calendars that may be valid. Only the CUA/CU and
> >  > perhaps the CS knows. Maybe the resources for that time slot
> >  > are not filled up.
> >
> > Huh!?!?!  Exactly when would a potential user of a resource want to know
> > the ABSOLUTE WRONG busytime information about that resource?!
>
> Never - and it is a good thing that we agree that a CUA/CS should
> never report ABSOLUTE WRONG busytime information.
Goodness that we do agree (and I suspect we agree on other points too).  

However I strongly think that allowing/expecting the CUAs to do VFREEBUSY creation/maintenance (as appears to be the implicit expectations now) is VERY BAD and should be prevented.  I expect that you would also agree to this in concept but maybe not in how its achieved (or maybe not 100% entirely).

> However for resource calendars mapping components to busytime
> is not always 1:1. There can be BUSY time with no entries in any
> calendar.

Sounds like you are taking about profilable 'work hours' or 'available hours' so that folks know "When is Doug available for meetings?" or "When is Room 1 'accessible'?".

More nifty features we've had in Notes for years now.  While I like that concept I do not expect it to be in CAP 1.0.  For CAP 1.0 I think that having VFREEBUSYs reflect just the calendar contents is a good first step.  Adding stuff like this post-CAP 1.0 is the way to go I think....

>            And for resource calendars you can have entries that
> do not create busy time. Think of a pool of conference rooms
> with similar properties.

"Pooling" is like "group calendars" and NOT something we are building in CAP 1.0.   Not a worthwhile example to use now...

>                           The busy time is not filled in until
> all of the conference rooms are booked.

Ahh, I see now.  Rolling up the busytime of several rooms into 1 'master' busytime entry is something that I agree that was quashed in 1999 by the WG.  In your view, when building a busytime roll-up system the busytime may not reflect just the contents of a calendar because it may be rolled up from others instead (or in addition?).  In any case, this is NOT something Im concerned with and I think is a confusing factor in this discussion.

Each separate room is busy if its booked and as such MUST be reflected in a busytime lookup for that room if checked directly.

> The rules of how to compute busy time vary depending on the
> application and user preferences (sleep time).
Not really.

If there is an entry on the calendar then its should be immediately reflected in the busytime data for that calendar.  The only reason for it to NOT appear that I can think of is that there may be a slight lag in creating the entry and it actually showing up in busytime (ie: a couple seconds delay as its processed and flushed to disk).

User preferences on when to compute busytime have NO input into the matter in a real time environment.  What user really wants to "Update my busytime 1 hour after I add any new entries."?

I get calls about "This morning I put an appointment on my calendar for 3PM on Tuesday but when Sue checks my busytime it appears as if Im free.  Why?".  I NEVER get calls "I put 2 appointments on my calendar this just now but I dont want them to show up in busytime until tonight.  How do I do this?".

> > If busytime is NOT 'in sync' (within some reasonable window) then it is
> > useless to anyone that would use it.
>
> We agree - it is reasonable for them to be out of sync :-)
More goodness...

> > Inaccurate busytime information is
> > worse than NO busytime information because it leads to nothing but
> > frustration and extra workflow ("Gee your busytime said you were free in
> > the AM but not in the PM but you say you only have a 9AM meeting.  If I
> > had known I could have invited Pat as well.  Now Ill have to try again.").
>
> 'Inaccurate' is only relative to the correctness of busy time for the
> owning CU. If they compute more busy time that your application then
> it is not inaccurate - you simply do not know how they computed it.
I think I now how to do busytime; Im the guy responsible for it in Lotus Notes and have been for since nearly the initial release of it Notes.

Correctness is relative to the calendars contents, not the CUs opinion of how busytime should look.  If CUs want to achieve something then the CUA simply constructs the proper calendar entry and it gets reflected in busytime.  To 'undo' the effect they change or remove the entry.  Trying to do manual maintenance of busytime of 'non-calendar entires' on an ad-hoc basis and NOT basing it on calendar data is too error prone to be of any good.  

> The same is true for resource calendars. Just because 1 of the pool
> of conference rooms [Snip]

Bringning up pooling or calendar / busytime roll-up is a digression from the base issue I started with and has already been quashed.  Lets not try to use it now in resolving my questions please.

>
> >  >                      I could have different constraints such as blocking
> >  > out 9PM-6AM in the VFREEBUSY and never allowing any component to book
> >  > at those times.
> >
> > Booking is totally separate from busytime.  
>
> We agree. They are not going to always be in sync.
My point was that the ability to book an entry is a completely separate issue from "Is Doug free @ 7PM EST for a meeting?".  I may see you are busy from 6PM thru 9AM but I may still be able to CREATE a meeting invitation for that time.  Busytime has no policy impact on entry creation.  That is NOT to say that once booked for 7PM - 8PM EST your busytime is NOT reflective of the new entry!

For CAP 1.0 Im NOT trying to build the most robust busytime system with tons of cool features.  Its too close to ship date.  Im trying to make sure that I can do the most elementary busytime lookups in CAP and be somewhat secure in the results returned are accurate of the calendars current status.

> > I can always overbook (assuming the 'conflict settings' of the conflicts
> > allow it) no matter what the busytime settings say ("I now I already
> > have a meeting at 9AM, save this one anyway!")!  Busytime merely informs
> > the viewer of entries in the calendar; it has 0, NONE, ZIP effect on any
> > kind of booking policy.  Thats a totally separate issue.  
>
> Which is exactly my point. How that time is computed is going to have
> to be flexible.
Not sure I follow here.  You agree that busytime is informative and has no effect on the booking policy of the user.  I assume that you also agree then that once a new entry is booked that it MUST be reflected in a subsequent busytime lookup.  I for one think that the CS is the place to do that maintenance, NOT the CUA.  I also think that this needs to be in CAP 1.0 for busytime to be even remotely useable 'out of the gates'.  Would you agree?

> >  >                 My VFREEBUSY time and the objects in my calendar
> >  > would then never be in sync. I could insert data in my VFREEBUSY time
> >  > for a 1 week vacation and not (see previous e-mail) have X number
> >  > of OPAQUE entries in my calendar for the 1 week vacation.
> >
> > And I could still try to book a meeting with you then as the CS has
> > NOTHING in it for that time that is marked as TRANSP:OPAQUE-NOCONFLICT.
> >  So what was achieved??
>
> If you or your CUA choose to ignore that that week is shown as
> busy time, then when I get back from vacation I would decline your
> METHOD:REQUEST.
Whats there for me or my CUA to ignore?  There has been NO change proposed to fbtypeparam to include "no conflict" as a 'type' of FREEBUSY.  In addition new "no conflict" types are for CAPs use so that when someone trys to overbook they are prevented.  

It sounds as if you are implicitly expecting that all attempts at workflow are somewhat controlled by busytime results ("You cannot meet with Pat @ 3PM, she has an entry that does not allow you to overbook!"). I think this is the wrong approach to take in using busytime.  Busytime is informative only.  It SHOULD be accurate but it SHOULD NOT prevent you from inviting Pat to that meeting.  She may see your REQUEST, decide to try and call in and allow herself to be overbooked (its HER choice).  She may see it and COUNTER you to a better time.  The "no conflict" control should only be enforced by the CS and the calendar CU has the final arbitration in allowing stuff like conflicts, etc.  Busytime does NOT.

In any case we have greatly digressed from my original question and Im still looking for the answer:

How do I get busytime information from other users via CAP?  (The followon question seems to be Who is responsible for keeping the busytime information updated and when?)

>    (1) You do not have access to the other entries.
I dont need access to the other entries for the CS to see that they are "no conflict" and thus prevent my booking a conflict.  Only the CS needs that access so it can reject the CREATE.

>    (2) I did not want to make X number of entries in my calendar to
>        each marked as vacation in order to work around my regular
>        entries that are OPAQUE that keep me from making 1 single
>        vacation entry.
You as the CUA have the final say so in allowing conflicts to your own calendar.  As such you should be able to create any kinds of entries you like whenver you want.  Any other design is fundamentally flawed.

>    (3) I did not want to delete my regular OPAQUE entries for that
>        week, so I just told my CUA to deposit a VFREEBUSY info
>        my calendar showing that I am busy that week.
See #2...

>
> > I have plenty of first hand experience dealing with disjoins between
> > calendars and busytime results so I am very confident in this being the
> > norm rather than an exception.
>
> I think we agree - they do not have to be in sync.
Still more goodness...

> > Yes it is.  It also happens to be easily demonstrable that if you
> > provide incorrect or misleading busytime information you GREATLY
> > increase user frustration and dissatisfaction with the feature to the
> > point that they wont use it at all!
>
> It not incorrect busy time. It just not computed the same way
> as you compute yours.
It boils down to who maintains the busytime then.  

I contend that only the CS can consitantly and accurately represent the busytime of a calendar within it and that a CUA may be able to but not in consistant and accurate manner without becoming overly burdensome.  If the design of CAP is such that its indeterminate who is to maintain the busytime info then I think its a fundamental flaw in CAP.

> SELECT * FROM VFREEBUSY where DTSTART > something AND DTEND < something-eles.
Hmm, 2 problems with this:

1: Thats different from your original answer of "its the same as in iTIP".  Under that mode the CUA would CREATE a VFREEBUSY REQUEST and then have to poll _someplace_ TBD for the VFREEBUSY REPLY.  Im not sure which is how you think CAP specifies it...

2: VFREEBUSYs use DTSTART / DTEND to delimit the bounds for the contained busytime information.  Unless you build some better selection criteria OR you coerce the DTSTART / DTEND pairs to be similar in duration your SEARCH may not find VFREEBUSYs that it should.  

For example, if the VFREEBUSY info within the CS is stored using day increments (ie: DTSTART:20030402 / DTEND:20030402  for yesterday, DTSTART:20030403 / DTEND:20030403 for today, etc) but your SEARCH criteria is simply for "When is Doug free this AM" (ie: DTSTART:20030403T120000Z / DTEND:20030403T170000Z) then NO VFREEBUSYs would match the SEARCHs' WHERE clause and NOTHING would get returned because the DTEND of the SELECT is _before_ the DTEND of the VFREBUSY for today!  

The ONLY way to use the kind of SEARCH you suggest is to search for a matching time slice and then ignore what I dont need.  For example, I may want to know "When is Doug free this AM" but my SEARCH would have know to use "WHERE DTSTART >= 20030403 AND DTEND <= 20030404" and then just ignore all the extra data it gets back.  This of course means that the CUA would have to know the granularity of the VFREEBUSY data its searching AND that the potential waste of bandwidth with the extra data is a necessary evil...

> You have given examples yourself in your email that it is valid
> to not always be in sync. (The one I am replying to with this
> message).
Having a small window where they are not in sync is acceptable (ie: the time it takes to process it and save the 'cache' info to disk).  Thats the ONLY time it wont be in sync that Ive ever mentioned as not evil!  Yesterday, Doug claimed that agregious discrepancies were ok:

> That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today
> but the VFREEBUSY data on my calendar says Im
> FREEBUSY:20030402T060000Z/20030402T063000Z.  This makes busytime useless
> for trying to schedule with me.

For some resource calendars that may be valid.

but I have yet to hear any validation of this claim.  

When is having data that does NOT represent the calendars contents or even blatently misrepesents it a 'valid' case?!?  

Busytime should always accurately reflect the status of the calendar based on its contents!  

And still I dont see where in CAP I overlooked where it "specifies how to search for available busy time information"...  Maybe I need some glasses.

Waiter!!

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 007528D985256CFD_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 3 16:46:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15811 for ; Thu, 3 Apr 2003 16:46:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33LbGJM015569 for ; Thu, 3 Apr 2003 13:37:16 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33LbG3h015568 for ietf-calendar-bks; Thu, 3 Apr 2003 13:37:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h33LbFJM015563 for ; Thu, 3 Apr 2003 13:37:15 -0800 (PST) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 03 Apr 2003 14:24:36 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 03 Apr 2003 14:36:12 -0700 From: "Preston Stephenson" To: "<" Subject: How do you get the METHOD property on a SEARCH Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Was this discussed before and I just missed it? I have two users with two CUA's, CUA1 and CUA2. CUA1 creates a VEVENT with METHOD:REQUEST in CUA2's calendar. How does CUA2 get the METHOD property with that VEVENT? The search logic only returns VEVENT's. How do you associate the METHOD with the VEVENT since it is outside the VEVENT? For example in section 6.1.1.18 there is the query: BEGIN:VQUERY QUERYID:Fetch VEVENT and VTODO iTIP components QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' QUERY:SELECT * FROM VTODO WHERE STATE() = 'UNPROCESSED' END:VQUERY The query would return the VEVENT's and the VTODO's. Would you need to explicitly ask for each method type? QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' AND METHOD = 'REQUEST' Thanks. Preston PS In the CAP spec there is an example in section 8.33 on the RESTRICTION property: RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' VCALENDAR is not defined in the comp-name ABNF. From owner-ietf-calendar@mail.imc.org Thu Apr 3 17:41:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17666 for ; Thu, 3 Apr 2003 17:41:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33MW5JM018447 for ; Thu, 3 Apr 2003 14:32:05 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33MW5kS018446 for ietf-calendar-bks; Thu, 3 Apr 2003 14:32:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33MW2JM018442 for ; Thu, 3 Apr 2003 14:32:03 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 3 Apr 2003 17:07:55 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/03/2003 05:32:05 PM, Serialize complete at 04/03/2003 05:32:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0079430A85256CFD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079430A85256CFD_= Content-Type: text/plain; charset="US-ASCII" On 4/1/2003 Doug started a sub-thread with the claim that busytime is NOT a requirement of CAP (See Subject above). This is NOT true. The CAP requirements on this are pretty clear: 4.5.1 Lookup CAP MUST specify, subject to access control: ... - How the CUA can retrieve all the free/busy data for a calendar. and 4.5.3 Specific Queries These are specific scenarios required by calendaring operations which may require special attention to ensure that they can be done with the querying and lookup functionality of CAP. CAP MUST allow, subject to access control: ... - The CUA to discover conflicts given a list of calendars and a time period This feature is to allow the CUA to schedule a group of attendees for a meeting at a particular time; the CUA MUST be able to find out if those attendees are free at that time. Perhaps I misinterpreted them but I dont think so. So far Ive heard 2 different answers how to query for busytime. Yet there is no text in CAP to satisfy this requirement. I think there should be some prose added so that the way to do busytime lookups is 100% unambiguious and that all CUAs implement it the same way ("Remember Multipart!!"). So far Ive seen ~5 votes for this too (wake up your ~290 others out there!) The rest of the flurry of late seems to dive on who should be responsible for the busytime information and on that the CAP requirements seem to have a hole in them. There is a requirement to be able to query for busytime and there is a deferral of busytime rollup that Doug did mentinoed: 4.5.5 Deferred Requirements for Search CAP is not required to specify: - How to roll up free/busy information for a number of calendars (perhaps sub-calendars) into a single free/busy component. However there seems to be 1 oversight in the CAP requirements: WHO is responsible for maintaining busytime data? So far the majority of comments seem to concur that dynamic busytime generation is the way to go but Doug has maintained that its the CUAs job or a combination of the CUA and some unspecified CS mechanism. I for one think that we need to step back, take a deep breath (or sigh) and refocus on first issue: There is no text in CAP 1.0 to fulfill the requirements above. Then I think we need to fix the oversight on busytime maintenance and get that in to CAP 1.0 and not leave it for interpretation by each reader. Only then can we expect successful interoperabilty using CAP. 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 0079430A85256CFD_= Content-Type: text/html; charset="US-ASCII"
On 4/1/2003 Doug started a sub-thread with the claim that busytime is NOT a requirement of CAP (See Subject above).

This is NOT true.  The CAP requirements on this are pretty clear:

4.5.1   Lookup

  CAP MUST specify, subject to access control:
...
    - How the CUA can retrieve all the free/busy data for a calendar.
and

4.5.3   Specific Queries

  These are specific scenarios required by calendaring operations which
  may require special attention to ensure that they can be done with
  the querying and lookup functionality of CAP.

  CAP MUST allow, subject to access control:
...
     - The CUA to discover conflicts given a list of calendars and a
    time period

      This feature is to allow the CUA to schedule a group of
      attendees for a meeting at a particular time; the CUA MUST be
      able to find out if those attendees are free at that time.

Perhaps I misinterpreted them but I dont think so.  So far Ive heard 2 different answers how to query for busytime.  Yet there is no text in CAP to satisfy this requirement.  

I think there should be some prose added so that the way to do busytime lookups is 100% unambiguious and that all CUAs implement it the same way ("Remember Multipart!!").   So far Ive seen ~5 votes for this too (wake up your ~290 others out there!)

The rest of the flurry of late seems to dive on who should be responsible for the busytime information and on that the CAP requirements seem to have a hole in them.  There is a requirement to be able to query for busytime and there is a deferral of busytime rollup that Doug did mentinoed:

4.5.5   Deferred Requirements for Search

  CAP is not required to specify:

    - How to roll up free/busy information for a number of calendars
    (perhaps sub-calendars) into a single free/busy component.

However there seems to be 1 oversight in the CAP requirements: WHO is responsible for maintaining busytime data?  

So far the majority of comments seem to concur that dynamic busytime generation is the way to go but Doug has maintained that its the CUAs job or a combination of the CUA and some unspecified CS mechanism.  I for one think that we need to step back, take a deep breath (or sigh) and refocus on first issue: There is no text in CAP 1.0 to fulfill the requirements above.

Then I think we need to fix the oversight on busytime maintenance and get that in to CAP 1.0 and not leave it for interpretation by each reader.  Only then can we expect successful interoperabilty using CAP.

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 0079430A85256CFD_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 3 17:59:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18073 for ; Thu, 3 Apr 2003 17:59:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33MowJM019194 for ; Thu, 3 Apr 2003 14:50:58 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33MowR0019193 for ietf-calendar-bks; Thu, 3 Apr 2003 14:50:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33MouJM019186 for ; Thu, 3 Apr 2003 14:50:56 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP / Busytime Restart MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 3 Apr 2003 17:43:57 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/03/2003 05:50:56 PM, Serialize complete at 04/03/2003 05:50:56 PM Content-Type: multipart/alternative; boundary="=_alternative 007C8F8C85256CFD_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007C8F8C85256CFD_= Content-Type: text/plain; charset="US-ASCII" In trying to take a step back some background checking was in order. Back in CAP-03 we had: [Editor's notes: Issues: freebusy - a cap server should dynamically calculate freebusy information - we recommend that you cannot create, modify, or delete freebusy composers ] and 9.1.54. VFREEBUSY schema An implementation may not actually have a VFREEBUSY table as the information may be produced dynamicly. However a CS MUST appear to provide this table as this may be how a CUA chooses to query for VFREEBUSY information while using [CAP]. In CAP-05 another issue was added: [EDITORS NOTE: Issues: [Snip] - We should not be able to delete any VFREEBUSY components? Somehow all this text was removed from CAP in CAP-06 without any WG discussion and I now find: It is important to note that scheduled components do not show up in busy time as BUSY. Only when they are booked does the TRANSP:OPAQUE property take effect. A CS implementation MAY mark the time as TENTATIVE. This new text implys that the CS does the busytime maintenance and NOT anyone else but its not made clear or definitive. So sometime between July 2001 and Nov 2001 the Issue got quietly removed and we are now left floundering. Unfortunately the latest CAP-10 Draft has loss even more text and the result is the current confusion. I think we should reinstate the Editors text as Draft Text and clearly and unambiguiously specify _THE_ way that busytime lookups are to be done in CAP and then we can go to Last Call! 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 007C8F8C85256CFD_= Content-Type: text/html; charset="US-ASCII"
In trying to take a step back some background checking was in order.  Back in CAP-03 we had:

[Editor's notes: Issues:
freebusy - a cap server should dynamically calculate
freebusy information - we recommend that you cannot create,
modify, or delete freebusy composers ]
and

9.1.54.    VFREEBUSY schema
 An implementation may not actually have a VFREEBUSY table
as   the
 information may be produced dynamicly. However a CS MUST
appear to
 provide this table as this may be how a CUA chooses to
query     for
 VFREEBUSY information while using [CAP].

In CAP-05 another issue was added:

   [EDITORS NOTE: Issues:
[Snip]
     - We should not be able to delete any VFREEBUSY components?
Somehow all this text was removed from CAP in CAP-06 without any WG discussion and I now find:

   It is important to note that scheduled components do not show up in
  busy time as BUSY.  Only when they are booked does the TRANSP:OPAQUE
  property take effect.  A CS implementation MAY mark the time as
  TENTATIVE.

This new text implys that the CS does the busytime maintenance and NOT anyone else but its not made clear or definitive.  

So sometime between July 2001 and Nov 2001 the Issue got quietly removed and we are now left floundering.  Unfortunately the latest CAP-10 Draft has loss even more text and the result is the current confusion.

I think we should reinstate the Editors text as Draft Text and clearly and unambiguiously specify _THE_ way that busytime lookups are to be done in CAP and then we can go to Last Call!

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 007C8F8C85256CFD_=-- From owner-ietf-calendar@mail.imc.org Fri Apr 4 01:34:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27371 for ; Fri, 4 Apr 2003 01:34:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h346BZJM013290 for ; Thu, 3 Apr 2003 22:11:35 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h346BZia013289 for ietf-calendar-bks; Thu, 3 Apr 2003 22:11:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h346BXJM013278 for ; Thu, 3 Apr 2003 22:11:33 -0800 (PST) Received: from guyver.demon.co.uk ([158.152.137.78] helo=localhost.localdomain) by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1) id 191KQI-000CCV-0X for ietf-calendar@imc.org; Fri, 04 Apr 2003 07:11:35 +0100 Received: from [192.168.1.121] ([192.168.1.121]) by localhost.localdomain (8.11.6/8.11.2) with ESMTP id h33Jm1l22805 for ; Thu, 3 Apr 2003 20:48:01 +0100 Subject: Re: Fw: CAP & busytime? - not CAP reqirement - CUA-BOT From: Martin Jackson To: ietf-calendar In-Reply-To: References: Content-Type: text/plain Message-Id: <1049399106.29136.1.camel@gasaraki.virtual.bogus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 03 Apr 2003 20:45:07 +0100 Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 7 Martin Jackson On Thu, 2003-04-03 at 16:49, Robert_Ransdell@notesdev.ibm.com wrote: > 6 > Tom Ransdell > > ----- Forwarded by Robert Ransdell/Westford/IBM on 04/03/2003 10:46 AM > ----- > "Preston Stephenson" > > Sent by: > owner-ietf-calendar@mail.imc.org > > 04/02/2003 08:06 AM > To > "<" > cc > > Subject > RE: CAP & > busytime? - not > CAP reqirement - > CUA-BOT > > > > > 5 > Preston > > >>> "Paul B. Hill" 4/1/2003 4:04:02 PM >>> > > OK, we're up to 4. Keep those "votes" coming :) > > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]OnBehalf Of Dan Winship > Sent: Tuesday, April 01, 2003 4:58 PM > To: ietf-calendar@imc.org > Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT > > > > On Tue, 2003-04-01 at 14:58, Doug Royer wrote: > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > > > > The only reasonble source for keeping the VFREEBUSY accurate is to > have > > > it done by the CS as changes are made to the calendar. _Assuming_ > that > > > an unspecified "Bot" mechanism is the way that it > should/would/MAY be > > > done is NOT sufficient here if we want that key functionality in > CAP. > > > CAP 1.0 needs to provide that basic functionality in it or we > severly > > > risk loosing user adoption. > > > > Need told me and Pat repeated that we can not add features to CAP > > unless 20 people on this list insist tht it must be done. > > Well, I agree with Bruce, so there's 2... > > -- Dan -- Martin Jackson -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-ietf-calendar@mail.imc.org Fri Apr 4 08:39:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21563 for ; Fri, 4 Apr 2003 08:39:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34DOnJM002541 for ; Fri, 4 Apr 2003 05:24:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34DOn4R002540 for ietf-calendar-bks; Fri, 4 Apr 2003 05:24:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h34DOlJM002531 for ; Fri, 4 Apr 2003 05:24:47 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040408291423087 for ; Fri, 04 Apr 2003 08:29:14 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 08:22:30 -0500 Message-ID: <3E8D8716.50507@centive.com> Date: Fri, 04 Apr 2003 08:22: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: ietf-calendar@imc.org Subject: Re: CAP / Busytime Restart References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2003 13:22:30.0645 (UTC) FILETIME=[3E9B5A50:01C2FAAD] 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: > Somehow all this text was removed from CAP in CAP-06 without any WG > discussion and I now find: [...] > I think we should reinstate the Editors text as Draft Text and clearly > and unambiguiously specify _THE_ way that busytime lookups are to be > done in CAP and then we can go to Last Call! I agree--unless someone can find evidence that WG discussion occurred after all. (No slam on Bruce here; the mailing list archive isn't that easy to search. Someone who remembers the discussion, if there was one, or whoever removed the text, might know better what to search for.) -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 4 10:30:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26374 for ; Fri, 4 Apr 2003 10:30:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FC6JM011551 for ; Fri, 4 Apr 2003 07:12:06 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FC6g9011550 for ietf-calendar-bks; Fri, 4 Apr 2003 07:12:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FC3JM011545 for ; Fri, 4 Apr 2003 07:12:04 -0800 (PST) In-Reply-To: <3E8D8716.50507@centive.com> To: ietf-calendar@imc.org Subject: Re: CAP / Busytime Restart MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Apr 2003 10:01:44 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/04/2003 10:11:50 AM, Serialize complete at 04/04/2003 10:11:50 AM Content-Type: multipart/alternative; boundary="=_alternative 005238F985256CFE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005238F985256CFE_= Content-Type: text/plain; charset="US-ASCII" John wrote on 04/04/2003 08:22:30 AM: > I agree--unless someone can find evidence that WG discussion occurred > after all. (No slam on Bruce here; the mailing list archive isn't that > easy to search. None taken. I have a personal archive of nearly all WG traffic going back to BOF days at Netscape. Im sure I missed one or two msgs here or there over 6+ years but its virtually complete (AND its fully threaded!). Unfortunately I no longer have the ability to host that outside the Intranet (IBM security policy) so Ive given it to Pat. Perhaps she can host it and the FT index so that anyone else can search as they like. If anyone out there has a Notes server and has ~190M of free disk Ill be happy to FTP it to ya... 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 005238F985256CFE_= Content-Type: text/html; charset="US-ASCII"
John wrote on 04/04/2003 08:22:30 AM:
> I agree--unless someone can find evidence that WG discussion occurred
> after all.  (No slam on Bruce here; the mailing list archive isn't that
> easy to search.

None taken.  I have a personal archive of nearly all WG traffic going back to BOF days at Netscape.  Im sure I missed one or two msgs here or there over 6+ years but its virtually complete (AND its fully threaded!).  

Unfortunately I no longer have the ability to host that outside the Intranet (IBM security policy) so Ive given it to Pat.  Perhaps she can host it and the FT index so that anyone else can search as they like.  

If anyone out there has a Notes server and has ~190M of free disk Ill be happy to FTP it to ya...

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 005238F985256CFE_=-- From owner-ietf-calendar@mail.imc.org Fri Apr 4 10:35:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26551 for ; Fri, 4 Apr 2003 10:35:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FKnJM012208 for ; Fri, 4 Apr 2003 07:20:49 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FKnGj012201 for ietf-calendar-bks; Fri, 4 Apr 2003 07:20:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h34FKiJM012153 for ; Fri, 4 Apr 2003 07:20:44 -0800 (PST) To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP / Busytime Restart MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 4 Apr 2003 10:20:54 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/04/2003 10:20:46 AM, Serialize complete at 04/04/2003 10:20:46 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hm, I think I agree. I say this even though I know it opens a can of worms. However, I for one think we need to have a decision on what to do with the FreeBusy updates. Bruce_Kahn@notesdev.ibm.com Sent by: owner-ietf-calendar@mail.imc.org 04/03/2003 17:43 To: ietf-calendar@imc.org cc: Subject: CAP / Busytime Restart In trying to take a step back some background checking was in order. Back in CAP-03 we had: [Editor's notes: Issues: freebusy - a cap server should dynamically calculate freebusy information - we recommend that you cannot create, modify, or delete freebusy composers ] and 9.1.54. VFREEBUSY schema An implementation may not actually have a VFREEBUSY table as the information may be produced dynamicly. However a CS MUST appear to provide this table as this may be how a CUA chooses to query for VFREEBUSY information while using [CAP]. In CAP-05 another issue was added: [EDITORS NOTE: Issues: [Snip] - We should not be able to delete any VFREEBUSY components? Somehow all this text was removed from CAP in CAP-06 without any WG discussion and I now find: It is important to note that scheduled components do not show up in busy time as BUSY. Only when they are booked does the TRANSP:OPAQUE property take effect. A CS implementation MAY mark the time as TENTATIVE. This new text implys that the CS does the busytime maintenance and NOT anyone else but its not made clear or definitive. So sometime between July 2001 and Nov 2001 the Issue got quietly removed and we are now left floundering. Unfortunately the latest CAP-10 Draft has loss even more text and the result is the current confusion. I think we should reinstate the Editors text as Draft Text and clearly and unambiguiously specify _THE_ way that busytime lookups are to be done in CAP and then we can go to Last Call! 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 Fri Apr 4 10:36:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26585 for ; Fri, 4 Apr 2003 10:36:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FKSJM012056 for ; Fri, 4 Apr 2003 07:20:28 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FKSgu012055 for ietf-calendar-bks; Fri, 4 Apr 2003 07:20:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FKQJM012028 for ; Fri, 4 Apr 2003 07:20:26 -0800 (PST) Received: (qmail 17692 invoked from network); 4 Apr 2003 15:20:22 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 4 Apr 2003 15:20:22 -0000 Subject: Re: How do you get the METHOD property on a SEARCH From: Dan Winship To: Preston Stephenson Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1049469630.26767.10.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 04 Apr 2003 10:20:30 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Would you need to explicitly ask for each method type? > > QUERY:SELECT * FROM VEVENT WHERE > STATE() = 'UNPROCESSED' AND METHOD = 'REQUEST' If I understand things correctly, that would mean "where *the VEVENT's* METHOD is 'REQUEST'", which would be invalid because VEVENTs don't have METHODs. So that won't work either. -- Dan From owner-ietf-calendar@mail.imc.org Fri Apr 4 10:39:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26706 for ; Fri, 4 Apr 2003 10:39:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FOKJM012779 for ; Fri, 4 Apr 2003 07:24:20 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FOKDU012778 for ietf-calendar-bks; Fri, 4 Apr 2003 07:24:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h34FOIJM012757 for ; Fri, 4 Apr 2003 07:24:18 -0800 (PST) To: Martin Jackson Cc: ietf-calendar , owner-ietf-calendar@mail.imc.org Subject: Re: Fw: CAP & busytime? - not CAP reqirement - CUA-BOT MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 4 Apr 2003 10:24:28 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/04/2003 10:24:20 AM, Serialize complete at 04/04/2003 10:24:20 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ok, we're up to 7 people. That is an all time record for votes. Cool. Now, on to what we do. I know our AD said only if 20 people responded would we be allowed to "resurface" a problem. I'm making an executive decision here and re-opening this topic. It appears it may indeed be an issue and broken in the spec. However, that being said, I'd like to put a deadline on how quickly we get it resolved. So....., stepping into the pit of alligators.....I'd like to see this resolved, with text, within the next two weeks. I think that's doable. Anyone care to try to start this off. Martin Jackson Sent by: owner-ietf-calendar@mail.imc.org 04/03/2003 14:45 To: ietf-calendar cc: Subject: Re: Fw: CAP & busytime? - not CAP reqirement - CUA-BOT 7 Martin Jackson On Thu, 2003-04-03 at 16:49, Robert_Ransdell@notesdev.ibm.com wrote: > 6 > Tom Ransdell > > ----- Forwarded by Robert Ransdell/Westford/IBM on 04/03/2003 10:46 AM > ----- > "Preston Stephenson" > > Sent by: > owner-ietf-calendar@mail.imc.org > > 04/02/2003 08:06 AM > To > "<" > cc > > Subject > RE: CAP & > busytime? - not > CAP reqirement - > CUA-BOT > > > > > 5 > Preston > > >>> "Paul B. Hill" 4/1/2003 4:04:02 PM >>> > > OK, we're up to 4. Keep those "votes" coming :) > > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]OnBehalf Of Dan Winship > Sent: Tuesday, April 01, 2003 4:58 PM > To: ietf-calendar@imc.org > Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT > > > > On Tue, 2003-04-01 at 14:58, Doug Royer wrote: > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > > > > The only reasonble source for keeping the VFREEBUSY accurate is to > have > > > it done by the CS as changes are made to the calendar. _Assuming_ > that > > > an unspecified "Bot" mechanism is the way that it > should/would/MAY be > > > done is NOT sufficient here if we want that key functionality in > CAP. > > > CAP 1.0 needs to provide that basic functionality in it or we > severly > > > risk loosing user adoption. > > > > Need told me and Pat repeated that we can not add features to CAP > > unless 20 people on this list insist tht it must be done. > > Well, I agree with Bruce, so there's 2... > > -- Dan -- Martin Jackson -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-ietf-calendar@mail.imc.org Fri Apr 4 10:45:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26919 for ; Fri, 4 Apr 2003 10:45:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FR5JM013197 for ; Fri, 4 Apr 2003 07:27:05 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FR5UV013196 for ietf-calendar-bks; Fri, 4 Apr 2003 07:27:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h34FR1JM013180 for ; Fri, 4 Apr 2003 07:27:03 -0800 (PST) To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP / Busytime Restart MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 4 Apr 2003 10:27:11 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/04/2003 10:27:05 AM, Serialize complete at 04/04/2003 10:27:05 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John, I archived "most" of the IETF emails. I just set the file to go create and index and I'll search it to see what I can find. However, I think what happened is when the new editors took over working on the draft - they may have removed all the "Editors Comments" and not realized that nothing was in the text to resolve the issues. I know they were focused on getting transport stuff out and using BEEP. that's around the 06 timeframe ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke Sent by: owner-ietf-calendar@mail.imc.org 04/04/2003 08:22 To: ietf-calendar@imc.org cc: Subject: Re: CAP / Busytime Restart Bruce_Kahn@notesdev.ibm.com wrote: > Somehow all this text was removed from CAP in CAP-06 without any WG > discussion and I now find: [...] > I think we should reinstate the Editors text as Draft Text and clearly > and unambiguiously specify _THE_ way that busytime lookups are to be > done in CAP and then we can go to Last Call! I agree--unless someone can find evidence that WG discussion occurred after all. (No slam on Bruce here; the mailing list archive isn't that easy to search. Someone who remembers the discussion, if there was one, or whoever removed the text, might know better what to search for.) -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 4 10:51:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27256 for ; Fri, 4 Apr 2003 10:51:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FYZJM014288 for ; Fri, 4 Apr 2003 07:34:35 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FYZ9u014287 for ietf-calendar-bks; Fri, 4 Apr 2003 07:34:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h34FYYJM014253 for ; Fri, 4 Apr 2003 07:34:34 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040410390209366 for ; Fri, 04 Apr 2003 10:39:02 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 10:32:17 -0500 Message-ID: <3E8DA581.8090908@centive.com> Date: Fri, 04 Apr 2003 10:32:17 -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: CAP / Busytime Restart References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2003 15:32:17.0910 (UTC) FILETIME=[602DB160:01C2FABF] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: >However, I >think what happened is when the new editors took over working on the draft >- they may have removed all the "Editors Comments" and not realized that >nothing was in the text to resolve the issues. > Ah, yes, that would be an understandable mistake. Um...does that mean we should look back at -05 for editor's comments that -10 doesn't cover? (Doug, that's your cue to groan. ;-) -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 4 10:58:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27487 for ; Fri, 4 Apr 2003 10:58:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FghJM015483 for ; Fri, 4 Apr 2003 07:42:43 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34FggFP015482 for ietf-calendar-bks; Fri, 4 Apr 2003 07:42:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h34FgeJM015468 for ; Fri, 4 Apr 2003 07:42:40 -0800 (PST) To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org, John Stracke , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / Busytime Restart MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 4 Apr 2003 10:42:51 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/04/2003 10:42:42 AM, Serialize complete at 04/04/2003 10:42:42 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here's an old issues list I found on my archive. It's dated 7/16/2001. I think it might be helpful as we go through CAP to make sure it's ready for Last Call. Also, there is a section here on FREEBUSY (surprise). --------------------- - A number of issues with the various restriction tables. See CAP. - CS do not preserve data integrity. Explanation/example: someone can store a multipart/signed vEvent on their own calendar via CAP but when the owner goes to read it back the sig is gone (or its been 'resigned' by the CS). For multipart/encrypted, CS's may decrypt and later reencrypt data back but it data security/preservation is not available. A by-product of this is that when an invite arrives in your calendar scheduling queue all you will be able to tell is that your server says the data got there in some safe manner; no info as to the original signature, etc. As such anyone with a valid signature can send the calendar owner entries and the CAP server will say this was signed and CAP verified it was". In eMail you can see the senders signature (somewhere in the UI); with CAP you have no visual way to see _WHO_ signed it. Another way to look at this is: you sign and save an entry. Your AA or someone else w/access to it comes in and modifies it. You later go back and reopen the entry but you will have no visual clue as to its been changed by someone else since _I_ signed and saved it since my CAP server only says "This was really signed when it was saved". Is this OK? (from Bruce) - Security issue - mutual trust model. Is it in the draft? CAP implicitly requires some form of mutual trust model. Is this explicitly called out in the draft even though it is implict in the design? Once something is outside of a firewall it is out of your realm of control just like email. (from Bruce) - JIT signing/encryption: For some cases we may wind up having signing/encryption done by 'downstream' CS's as the request routes thru. ie: Paul @ MIT sent a REQUEST to his CS w/your CalID as 1 TARGET. He sends the data unsigned/encrypted to his CS. It sees your TARGET and by some TBD CS policy it decides that the data must be signed/encrypted so that it can go over, say, iMIP. His CS does not have his key so it simply uses its own. (Additionally, if his server fanned it out to outside the firewall before this happens, the signer/encryptor is not even his CS). So the first CS that can sign it does and then that is trackable all the way to you [after resigning by each subsequent CS in the flow path is done] (from Bruce) - "Fallback/fanout to iTIP" concerns: If CAP request must get turned into iTIP then some extra coding must occur (ie: rewriting the proper ATTENDEE and ORGANIZER values from cap://... to mailto:.. ). Since this may happen anywhere down stream from the originating CS, it is not guaranteed that the mapping/rewrites are accurate or correct; they are 'assumed' to be usable ("or the request is bounced back."). Unfortunately correctness is only positively done at the starting point and not @ Yahoo on the way to Lotus. There are also cases like signed or encrypted data that would prevent this from being either doable or run the risk of voiding the signature. (from Bruce) - The workflow path may not be a true path: The iTIP workflow path was a just that; a path (msg flow out followed same logical flow back). In CAP, if 'rerouting' over iTIP occurs then the path is now a loop (CUA1->CS1->iTIP to MUA2/CUA2->MUA1/(CUA1?). The last leg of getting iTIP/iMIP replies from the MUA1 to CUA1 so it can stuff them into CS1 in the "proper place" is just handwaved (or "left up to the user or their tools to do"). There is no clear why/how CUA1 would stuff in iTIP/iMIP messages into own queue instead of having CUA1 watch the incoming MUA1 queue for iTIP msgs and pulling them in or having CS1 rewrite the address so that msgs return to it directly. Paul or Doug state that users would only be confused (at best) or not aware of (at worse) any kind of signature msgs / warnings that they may see on their receiving end. Bruce feels email is stillok in that if my MUA can see the sig then it tells me "This msg was signed by Doug Royer and its valid". He does not think there is any usefulness in seeing "This request was signed and I, your trusted CS says its valid!" (esp. if we allow downstream servers to sign 'on your behalf' or 'at your behest' via some TBD mechanism). Is data integrity within the CS necessary? Do we trust the CS to enforce integrity or not. (from Bruce) - Look at changes required by CAP to make it compatible with CRISP - Add changes to iCalendar the are required for CAP - Do we want/need the CAP server to auto-mangle (aka autoinsert) an incoming stream of data with a generated UID? Especially if > 1 operation is going to be needed (ie: "Put this on my calendar and send invitations to the ATTENDEEs" = 1 CREATE and 1 or more other operations). Wouldn't it be simpler and more efficient to have the client request a UID and have the CAP server generate and return it (ala NNTP does with Message-IDs)?? Besides, the client will _probably_ need to have the UID for other operations (like saving in its local store if is does sync work!). (from Bruce) ToDos: ====== - Review restriction tables. - Review CAP Requirements doc to make sure that we have met all requirements. - Make sure that CAP supports synch. - Get CAP related changes into iCalendar - Resolve issues with the various methods (e.g., how does one specify a specific attachment during an update). - VTIMEZONE and IANA. (Doug's list) - Remove unused definitions (Doug's list). I assume this means that we should remove all definitions that are in the definition section, but that are not used in the text. - Document MAXSIZE and MAXRESULT (Doug's list). - Document METHOD is stored in CS database (Doug's list). - Only one 'CREATE' per UID (Doug's list). - Multiple non-CREATE per UID (Doug's list). - Fix the RESPONSE's to be consistent and multiple components, one for each TARGET (Doug's list). - Section 2.4.4.2 - editor note: We need an example (Steve/Doug). Paul needs to read this note an example. (Doug's list). - Merge changes Doug made into the doc. Some changes may no longer be appropriate (George). - Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve (Doug's list). - Section 7.1.3 Need to get IANA registration (Doug's list) - Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. (Doug's list). - Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. (Doug's list). - Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. (Doug's list). - Section 12.0 (was section 13) This section is not ready for prime time. Need Paul Hill. Need an editors note. (Doug's list). - Section 15.1.4 (now section ?) Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. (Doug's list) - Editor note: Remove references to VDATA (mistake) (Doug's list) - Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 (Doug's list) - Write ABNF for VQUERY. (George) - There were a few changes made by Doug in an interim document. These changes did not make the doc we submitted since we worked from another version of the doc. Most of these changes were new examples, or small changes to existing text. - Should we provide some kind of template to follow for all the application protocol commands (CREATE, MODIFY, etc). All we have right now is a brief description followed by an example. Is there anywhere where the syntax or form that should be followed clearly specified? - Need to register CAP port number. Prefered if number used is a small as possible. (Admins like to block whole rages of the higher port numbers.) May need to before CAP is an RFC before we can register it. - Go through past posts to see if there are any other issues - review syntax of all examples - may need to register the CAP URL (cap://) ?? Examples: ========= - search - security - fanout using iMIP - basic operations that a user may do during regular use (George) - the minimum data required to create an entry - an entire short session from login to download entries, to log out. - errors - The UIDs in our examples are different than the suggested format in iCAL. From CAP document: ================== - register "cap" service name for SASL with IANA - DISCONNECT: should the client now wait for a response from the server before disconnecting? - NOOP: should an unauthenticated and unidentified client be able to issue this command? - NOOP: need to add NOOP in the state diagram? - GENERATEUID: the example needs work. It's not packaged right. - VQUERY: if the user does not have access to some, but not all of properties that were specified should the acessible properties be returned along with an error code - Error codes: missing ones for 6.XXX - What are the minimum component properties set required to create a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and UID. - What is the state of all undefined properties? PROPOSAL: Not defined. So a query will not return them, if they are selected. - DELETE: - Currently CAP requires that the server return a response status. However, if there are multiple components deleted, should the UID also be returned? - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to deletion? - Can one use DELETE to remove all VALARMs and VTIMEZONEs that match a certain search criteria and that belong to all components, event though VALARMs and VTIMEZONEs never exist as independent components? Or should one use MODIFY? If they can be deleted, do we return the REQUEST-STATUS of their deletion in a VEVENT or separately? - In the example in CAP where a calendar is deleted all the server returns is 2.0, nothing else? - We should not be able to delete any VFREEBUSY components? - Can we delete multiple calendars? - Currently one can not delete a VCALENDAR and some other component in the same DELETE command. This seems OK. Anyone see any need to be able to do this? - Should the MAXRESULTS property of VQUERY apply to deletion? We can use it to delete only the first n components that match. - FREEBUSY: a cap server should dynamically calculate freebusy information we recommend that you cannot create, modify, or delete freebusy composers - MOVE: 1) Should one be able to move a calendar owned by person X into a calendar owned by person Y. (Can these such rights be specified in VCARs?) 2) Should we also be able to move components from one calendar to another? What if the calendars are owned by different users? (With components one can do a copy, then delete the original.) 3) There was very little information about MOVE in CAP. Why was it added? Was there some major need for it? 4) Can one move multiple calendars into one calendar? - MODIFY: how does one modify an attachment? pregen@egenconsulting.com Sent by: owner-ietf-calendar@mail.imc.org 04/04/2003 10:27 To: John Stracke cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP / Busytime Restart John, I archived "most" of the IETF emails. I just set the file to go create and index and I'll search it to see what I can find. However, I think what happened is when the new editors took over working on the draft - they may have removed all the "Editors Comments" and not realized that nothing was in the text to resolve the issues. I know they were focused on getting transport stuff out and using BEEP. that's around the 06 timeframe ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke Sent by: owner-ietf-calendar@mail.imc.org 04/04/2003 08:22 To: ietf-calendar@imc.org cc: Subject: Re: CAP / Busytime Restart Bruce_Kahn@notesdev.ibm.com wrote: > Somehow all this text was removed from CAP in CAP-06 without any WG > discussion and I now find: [...] > I think we should reinstate the Editors text as Draft Text and clearly > and unambiguiously specify _THE_ way that busytime lookups are to be > done in CAP and then we can go to Last Call! I agree--unless someone can find evidence that WG discussion occurred after all. (No slam on Bruce here; the mailing list archive isn't that easy to search. Someone who remembers the discussion, if there was one, or whoever removed the text, might know better what to search for.) -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 4 11:02:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27626 for ; Fri, 4 Apr 2003 11:02:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34FkxJM016122 for ; Fri, 4 Apr 2003 07:46:59 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34Fkxcc016121 for ietf-calendar-bks; Fri, 4 Apr 2003 07:46:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h34FkvJM016109 for ; Fri, 4 Apr 2003 07:46:57 -0800 (PST) To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP / Busytime Restart MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 4 Apr 2003 10:47:08 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/04/2003 10:46:59 AM, Serialize complete at 04/04/2003 10:46:59 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bruce/John, my archives show a couple of discussions about FreeBusy. One set occurred in the May/June 2002 timeframe and then in the July/August 2001 timeframe and at the Pittsburg meeting. You can find the discussion on the minutes for that meeting. Here's a snippet of one of the July 2001 discussions: "Shannon J. Clark" wrote: > > Well a few points about doing it all client-side OR via an outside scheduler > (like cron). > > 1. - this does not resolve how my SERVER should handle incoming events in > the future - i.e. say I expand a "forever" event for the next 100 instances > (or any other arbitrary number) - if my FREEBUSY status is queried (which is > a feature CS can and should - but not must - support) for a time past that > arbitrary number then my server will return incorrect information. > Admittedly this probably is far in the future - and may get corrected after > my rule is expanded - but it changes the order of things in a strange (and > probably confusing to an end user) manner. If your server supports this extended functionality, that's a good server! > 2. - many CUA's will NOT have access to tools like cron - sure unix clients > have cron access easily - but such tools are confusing even for > sophisticated users - and do not help CUA cases for mobile devices, > notebooks, etc. Tools like cron are very simple to write. My wristwatch has a tool like cron: I can program it to beep at a specified time in the future. > Furthermore - if the client application is responsible for > expanding events - and then entering them into a calendar store - there > still is a requirement for a method of DEFINING how to expand events - the > purpose of a set of RRULES is to define a set of ALGORITHMS that can > generate a set of future events - thus avoiding the requirement that a HUMAN > "figure it out" The problem is interoperabioty, and complete specification of corner cases. By delegating solving that problem explicitly outside the scope of the standard, the interoperability problem goes away. Recurring language is reclassified to MAY status, and a way to specify which dialect you are speaking is provided. The world might wind up with only one dialect, but it might wind up with many: by delegating the detail the standard can support any possibility. > Even simple cases if required to be entered by hand > [...] shifting from RRULES on the server - to RRULES on the > client feels like a step backwards. Shifting functionality from the server to the client does not mean entering by hand. The client will still be a complex piece of software. Allowing variety in the client means more rocust competition, to argue from a free-market perspective. > (note on above, in the systems my company is designing we are indeed looking > carefully at this issue - but still plan on having server side knowledge of > the RRULES - even if we do some expansion of them in advance and cache it > for performance) > > Shannon I'll stand by what I recall my reccomendation here was, which, with very slight improvement, was: CS MUST accept multiple dates/times/locations for same event CS MUST list what RRULES languages it knows in its CAPABILITY responses CS SHOULD accept a minimal standard RRULES language which is fully defined CS MAY accept an extended RRULES language, which the definition of which is beyond the scope of this document. Bruce_Kahn@notesdev.ibm.com Sent by: owner-ietf-calendar@mail.imc.org 04/04/2003 10:01 To: ietf-calendar@imc.org cc: Subject: Re: CAP / Busytime Restart John wrote on 04/04/2003 08:22:30 AM: > I agree--unless someone can find evidence that WG discussion occurred > after all. (No slam on Bruce here; the mailing list archive isn't that > easy to search. None taken. I have a personal archive of nearly all WG traffic going back to BOF days at Netscape. Im sure I missed one or two msgs here or there over 6+ years but its virtually complete (AND its fully threaded!). Unfortunately I no longer have the ability to host that outside the Intranet (IBM security policy) so Ive given it to Pat. Perhaps she can host it and the FT index so that anyone else can search as they like. If anyone out there has a Notes server and has ~190M of free disk Ill be happy to FTP it to ya... 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 Fri Apr 4 16:07:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08213 for ; Fri, 4 Apr 2003 16:07:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34Ku4JM003205 for ; Fri, 4 Apr 2003 12:56:04 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34Ku4Ds003204 for ietf-calendar-bks; Fri, 4 Apr 2003 12:56:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34Ku3JM003198 for ; Fri, 4 Apr 2003 12:56:03 -0800 (PST) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: How do you get the METHOD property on a SEARCH MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Apr 2003 15:45:22 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/04/2003 03:55:50 PM, Serialize complete at 04/04/2003 03:55:50 PM Content-Type: multipart/alternative; boundary="=_alternative 0072F0B085256CFE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072F0B085256CFE_= Content-Type: text/plain; charset="US-ASCII" Preston asked on 04/03/2003 04:36:12 PM: > Was this discussed before and I just missed it? Nope. > How does CUA2 get the METHOD property with that VEVENT? Interesting quandry. The property you want/need is outside of the component you are SEARCHing for. I had thought perhaps you'd just SELECT VEVENT FROM * WHERE STATE()="UNPROCESSED" and TARGET each CUAs calendar but I strongly think thats illegal given the text of Section 6.1.1.5: Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" depending on the state of the object. In this new case the object in question is the calendar and NOT any workflow component so it will have NO STATE. The ABNF/ prose in 6.1.1.5 does NOT preclude using STATE() for objects that are non-workflow (ie: Calendars, TZ info, Alarms, etc) and that will lead to some kind of problem unless clarified. > How do you associate the METHOD with the VEVENT since it is outside the > VEVENT? "Ya can't get there from here!" All of us need the ability to get the higher level properties associated with the VEVENT but I cant see how we get it. Otherwise its impossible to tell a REPLY from a COUNTER from a REQUEST ... Hmm... > In the CAP spec there is an example in section 8.33 on the RESTRICTION > property: > > RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' > > VCALENDAR is not defined in the comp-name ABNF. Its actually there as VAGENDA. (Calendar was already taken as the outter container marker so we made each calendar an 'agenda'). 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 0072F0B085256CFE_= Content-Type: text/html; charset="US-ASCII"
Preston asked on 04/03/2003 04:36:12 PM:
> Was this discussed before and I just missed it?
Nope.

> How does CUA2 get the METHOD property with that VEVENT?
Interesting quandry.  The property you want/need is outside of the component you are SEARCHing for.

I had thought perhaps you'd just SELECT VEVENT FROM * WHERE STATE()="UNPROCESSED" and TARGET each CUAs calendar but I strongly think thats illegal given the text of Section 6.1.1.5:

Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" depending on the state of the object.

In this new case the object in question is the calendar and NOT any workflow component so it will have NO STATE.   The ABNF/ prose in 6.1.1.5 does NOT preclude using STATE() for objects that are non-workflow (ie: Calendars, TZ info, Alarms, etc) and that will lead to some kind of problem unless clarified.

> How do you associate the METHOD with the VEVENT since it is outside the
> VEVENT?
"Ya can't get there from here!"

All of us need the ability to get the higher level properties associated with the VEVENT but I cant see how we get it.  Otherwise its impossible to tell a REPLY from a COUNTER from a REQUEST ...  Hmm...

> In the CAP spec there is an example in section 8.33 on the RESTRICTION
> property:
>
>    RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'
>
> VCALENDAR is not defined in the comp-name ABNF.
Its actually there as VAGENDA.  (Calendar was already taken as the outter container marker so we made each calendar an 'agenda').

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 0072F0B085256CFE_=-- From owner-ietf-calendar@mail.imc.org Fri Apr 4 16:23:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08565 for ; Fri, 4 Apr 2003 16:23:21 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34LDRJM004371 for ; Fri, 4 Apr 2003 13:13:27 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34LDR77004370 for ietf-calendar-bks; Fri, 4 Apr 2003 13:13:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with SMTP id h34LDPJM004365 for ; Fri, 4 Apr 2003 13:13:26 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centive.com (NAVGW 2.5.2.11) with SMTP id M2003040416175323270 for ; Fri, 04 Apr 2003 16:17:53 -0500 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 16:11:09 -0500 Message-ID: <3E8DF4ED.5040805@centive.com> Date: Fri, 04 Apr 2003 16:11:09 -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: How do you get the METHOD property on a SEARCH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2003 21:11:09.0311 (UTC) FILETIME=[B6A348F0:01C2FAEE] 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: > > How does CUA2 get the METHOD property with that VEVENT? > > Interesting quandry. The property you want/need is outside of the > component you are SEARCHing for. Um...and so is any associated VTIMEZONE. If the request contained a VEVENT and a VTIMEZONE, how do you find the VTIMEZONE? -- /============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 4 18:24:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13785 for ; Fri, 4 Apr 2003 18:24:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h34N6rJM007589 for ; Fri, 4 Apr 2003 15:06:53 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h34N6rLc007588 for ietf-calendar-bks; Fri, 4 Apr 2003 15:06:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h34N6qJM007584 for ; Fri, 4 Apr 2003 15:06:52 -0800 (PST) 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 h34N6hM4021784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Apr 2003 15:06:46 -0800 Message-ID: <3E8E0FF1.30503@Royer.com> Date: Fri, 04 Apr 2003 16:06:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP / Busytime Restart References: <3E8DA581.8090908@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070508030708060303020900" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070508030708060303020900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit *ALL* draft versions of CAP are now on: http://www.calsch.org/ietf/drafts.html I welcome comments and feedback - John :-) John Stracke wrote: > > pregen@egenconsulting.com wrote: > >> However, I think what happened is when the new editors took over >> working on the draft - they may have removed all the "Editors >> Comments" and not realized that nothing was in the text to resolve the >> issues. >> > Ah, yes, that would be an understandable mistake. Um...does that mean > we should look back at -05 for editor's comments that -10 doesn't cover? > (Doug, that's your cue to groan. ;-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070508030708060303020900 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDQyMzA2MjVaMCMGCSqGSIb3DQEJBDEWBBSq nM+hzZ6vgQ0zOqqQDcq6NN49nDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEABMef75le1SCN Eo2pIJlayfVCO2cOFjp33kNfVUtHTiURMAY2nJ4yMRI+aUfINjhY8106XAToJHARsuUs7UPV gSChD5mWTJoOAZFtdpTpigq9p9GxSde7DnMNbrzhiHmVlyA1XbBMyBmM9SiIaOLQxEiR2/g0 SJpO7aIszIPO4SNUOhqd84XD4egOns1sjjvlq35X8my86zkFibAOBBwUWx40XeAgK/IQAAWu 4rOiInRAF+jWC4vjQc5akyOBR3sSr7TmD7fLkxOd2VaUkSBp97w1l0Jyxkkg25RHjkvFdomj QpNNYhjmP5GFyvwyfNBBabvc+mY6/0wJGGrI9VSRgQAAAAAAAA== --------------ms070508030708060303020900-- From owner-ietf-calendar@mail.imc.org Mon Apr 7 05:10:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12055 for ; Mon, 7 Apr 2003 05:10:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h378mgJM007225 for ; Mon, 7 Apr 2003 01:48:42 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h378mgBk007224 for ietf-calendar-bks; Mon, 7 Apr 2003 01:48:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h378mfJM007191 for ; Mon, 7 Apr 2003 01:48:42 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id B69DB155BE; Mon, 7 Apr 2003 10:48:32 +0200 (CEST) Date: Mon, 7 Apr 2003 10:48:31 +0200 From: Andrea Campi To: Preston Stephenson Cc: "<" Subject: Re: How do you get the METHOD property on a SEARCH Message-ID: <20030407084831.GA440@inet.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.4i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, first of all: I'm replying considering just my experience and my interpretation, I didn't check archives. On Thu, Apr 03, 2003 at 02:36:12PM -0700, Preston Stephenson wrote: > I have two users with two CUA's, CUA1 and CUA2. > > CUA1 creates a VEVENT with METHOD:REQUEST in CUA2's calendar. > How does CUA2 get the METHOD property with that VEVENT? > The search logic only returns VEVENT's. > How do you associate the METHOD with the VEVENT since it is outside the > VEVENT? > > For example in section 6.1.1.18 there is the query: > BEGIN:VQUERY > QUERYID:Fetch VEVENT and VTODO iTIP components > QUERY:SELECT * FROM VEVENT WHERE > STATE() = 'UNPROCESSED' > QUERY:SELECT * FROM VTODO WHERE > STATE() = 'UNPROCESSED' > END:VQUERY > > The query would return the VEVENT's and the VTODO's. > This query looks appropriate to me, yes. I'd expect the CAP to reply with something like: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR BEGIN:VCALENDAR METHOD:REPLY BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR and so on. So you have all the information you need; it's your choice how to keep that information around. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Apr 7 09:23:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19213 for ; Mon, 7 Apr 2003 09:23:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37D6mJM001104 for ; Mon, 7 Apr 2003 06:06:48 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37D6mxO001103 for ietf-calendar-bks; Mon, 7 Apr 2003 06:06:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37D6kJM001092 for ; Mon, 7 Apr 2003 06:06:46 -0700 (PDT) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Mon, 07 Apr 2003 06:53:42 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 07 Apr 2003 07:05:05 -0600 From: "Preston Stephenson" To: "<" Subject: Re: How do you get the METHOD property on a SEARCH Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 I'm still a little confused. On the query, I used an ID on the SEARCH command. How do I match up multiple VCALENDAR objects to one SEARCH command VCALENDAR object? How do I know there are multiple REPLY commands with the same ID? How do I know when there won't be any more REPLY commands to the one ID? Thanks. Preston >>> Andrea Campi 4/7/2003 2:48:31 AM >>> Hi all, first of all: I'm replying considering just my experience and my interpretation, I didn't check archives. On Thu, Apr 03, 2003 at 02:36:12PM -0700, Preston Stephenson wrote: > I have two users with two CUA's, CUA1 and CUA2. > > CUA1 creates a VEVENT with METHOD:REQUEST in CUA2's calendar. > How does CUA2 get the METHOD property with that VEVENT? > The search logic only returns VEVENT's. > How do you associate the METHOD with the VEVENT since it is outside the > VEVENT? > > For example in section 6.1.1.18 there is the query: > BEGIN:VQUERY > QUERYID:Fetch VEVENT and VTODO iTIP components > QUERY:SELECT * FROM VEVENT WHERE > STATE() = 'UNPROCESSED' > QUERY:SELECT * FROM VTODO WHERE > STATE() = 'UNPROCESSED' > END:VQUERY > > The query would return the VEVENT's and the VTODO's. > This query looks appropriate to me, yes. I'd expect the CAP to reply with something like: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR BEGIN:VCALENDAR METHOD:REPLY BEGIN:VREPLY BEGIN:VEVENT ... END:VEVENT BEGIN:VEVENT ... END:VEVENT END:VREPLY END:VCALENDAR and so on. So you have all the information you need; it's your choice how to keep that information around. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Mon Apr 7 10:44:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22421 for ; Mon, 7 Apr 2003 10:44:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37EQoJM005175 for ; Mon, 7 Apr 2003 07:26:50 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37EQoQF005174 for ietf-calendar-bks; Mon, 7 Apr 2003 07:26:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37EQnJM005165 for ; Mon, 7 Apr 2003 07:26:49 -0700 (PDT) In-Reply-To: <20030407084831.GA440@inet.it> To: ietf-calendar@imc.org Subject: Re: How do you get the METHOD property on a SEARCH MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 7 Apr 2003 10:21:50 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/07/2003 10:26:40 AM, Serialize complete at 04/07/2003 10:26:40 AM Content-Type: multipart/alternative; boundary="=_alternative 004ED36285256D01_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004ED36285256D01_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 04/07/2003 04:48:31 AM: > This query looks appropriate to me, yes. I'd expect the CAP to > reply with something like: > > BEGIN:VCALENDAR > METHOD:REQUEST > BEGIN:VREPLY > BEGIN:VEVENT So you expect that the meta information in the _original_ containing VCALENDAR of the VEVENT would be copied in to the _response_ containing VCALENDAR?? Would that apply ONLY to METHOD or would/should that apply to ALL properties? Or did you forget that the QUERY was for VEVENTs and all their containing information and NOT for the VCALENDAR that the VEVENT was in which is where the METHOD property resides? > So you have all the information you need; it's your choice how to > keep that information around. Um, the SELECT did not SELECT the contents of the VEVENTs outter VCALENDAR, just the contents of the VEVENT so unless there is some implicit "When you give me VEVENTs (or VTODOs, etc) then you also MUST return the other properties in the associated containing VCALENDAR" then what Preston asked for is not possible as CAP is currently written. I would expect that the _response_ VCALENDAR would contain new properties and NOT all the properties of the original VCALENDAR. Also, would this apply to all types of objects or just to the core VEVENT/VTODO/VJOURNAL/VTIMEZONE/etc type ones? For example, would the information of a containing VEVENT be automatically copied/inserted when my CUA queries for VALARMs that TRIGGER in the next 10 minutes? It MAY be necessary to know something from the containing component... 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 004ED36285256D01_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 04/07/2003 04:48:31 AM:
> This query looks appropriate to me, yes. I'd expect the CAP to
> reply with something like:
>
> BEGIN:VCALENDAR
> METHOD:REQUEST
> BEGIN:VREPLY
> BEGIN:VEVENT
So you expect that the meta information in the _original_ containing VCALENDAR of the VEVENT would be copied in to the _response_ containing VCALENDAR??

Would that apply ONLY to METHOD or would/should that apply to ALL properties?  Or did you forget that the QUERY was for VEVENTs and all their containing information and NOT for the VCALENDAR that the VEVENT was in which is where the METHOD property resides?

> So you have all the information you need; it's your choice how to
> keep that information around.
Um, the SELECT did not SELECT the contents of the VEVENTs outter VCALENDAR, just the contents of the VEVENT so unless there is some implicit "When you give me VEVENTs (or VTODOs, etc) then you also MUST return the other properties in the associated containing VCALENDAR" then what Preston asked for is not possible as CAP is currently written.

I would expect that the _response_ VCALENDAR would contain new properties and NOT all the properties of the original VCALENDAR.  

Also, would this apply to all types of objects or just to the core VEVENT/VTODO/VJOURNAL/VTIMEZONE/etc type ones?  For example, would the information of a containing VEVENT be automatically copied/inserted when my CUA queries for VALARMs that TRIGGER in the next 10 minutes?  It MAY be necessary to know something from the containing component...

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 004ED36285256D01_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 7 12:34:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26323 for ; Mon, 7 Apr 2003 12:34:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GFgJM014238 for ; Mon, 7 Apr 2003 09:15:42 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37GFgfF014237 for ietf-calendar-bks; Mon, 7 Apr 2003 09:15:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37GFeJM014232 for ; Mon, 7 Apr 2003 09:15:40 -0700 (PDT) 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 h37GFZrl015241 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Apr 2003 09:15:39 -0700 Message-ID: <3E91A41D.7040504@Royer.com> Date: Mon, 07 Apr 2003 10:15:25 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: How do you get the METHOD property on a SEARCH References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030803090800080101010204" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030803090800080101010204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Andrea wrote on 04/07/2003 04:48:31 AM: > > This query looks appropriate to me, yes. I'd expect the CAP to > > reply with something like: > > > > BEGIN:VCALENDAR > > METHOD:REQUEST > > BEGIN:VREPLY > > BEGIN:VEVENT > > So you expect that the meta information in the _original_ containing > VCALENDAR of the VEVENT would be copied in to the _response_ containing > VCALENDAR?? > > Would that apply ONLY to METHOD or would/should that apply to ALL > properties? Or did you forget that the QUERY was for VEVENTs and all > their containing information and NOT for the VCALENDAR that the VEVENT > was in which is where the METHOD property resides? As METHOD belongs in the VCALENDAR, Andrea's reply is exactly what I was going to post. > > So you have all the information you need; it's your choice how to > > keep that information around. > > Um, the SELECT did not SELECT the contents of the VEVENTs outter > VCALENDAR, just the contents of the VEVENT so unless there is some > implicit "When you give me VEVENTs (or VTODOs, etc) then you also MUST > return the other properties in the associated containing VCALENDAR" then > what Preston asked for is not possible as CAP is currently written. Yes it is and I think that Andrea's response is the only viable solution. If you provide a query that returns multiple METHOD values, just reply with multiple VALENDARs. > I would expect that the _response_ VCALENDAR would contain new > properties and NOT all the properties of the original VCALENDAR. What *exactly* do you expect? > Also, would this apply to all types of objects or just to the core > VEVENT/VTODO/VJOURNAL/VTIMEZONE/etc type ones? For example, would the > information of a containing VEVENT be automatically copied/inserted when > my CUA queries for VALARMs that TRIGGER in the next 10 minutes? It MAY > be necessary to know something from the containing component... Did you have another proposal? As you know the PRODID and VERSION may also be supplied in the VCALENDAR reply even when they are not part of the original query. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030803090800080101010204 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDcxNjE1MjZaMCMGCSqGSIb3DQEJBDEWBBSh pXY1gKNfj2cAaUGggu66RUeVFzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAfWVS3XibmKzQ VXDJpdYpY6PGPIty6xSN6cvmps/DNEg2r7ViH7vnWkwNPQ38MRKwaEtiu1dC/vw7RcYt/dEd H4dvatZl1JER4IRHMitA8mtnVZ9Vy0PUf5UWJvp5ZdVdZFRqlKkEeuDJDSon6kCnY6XlUMPh wmmsKJrIRGl7kuCyy8P0yl+JmoFZD/beIsKlS+eFmYw6X8lsX3S+pMghgYDzrdZFZwNQ+iBH 3pF0BvmWM1nRUvEC2WwFO27RBpbSWg/bAq5dIKiOxwDGrEq+HOYZv4Ek84qTT6ejLRo/ef+H wTA4s1dsT83HBSloDv6aQ8nAKL+mF5dxY2Uvlt2d+gAAAAAAAA== --------------ms030803090800080101010204-- From owner-ietf-calendar@mail.imc.org Mon Apr 7 12:49:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27150 for ; Mon, 7 Apr 2003 12:49:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37GVQJM015217 for ; Mon, 7 Apr 2003 09:31:26 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37GVQsB015216 for ietf-calendar-bks; Mon, 7 Apr 2003 09:31:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37GVPJM015210 for ; Mon, 7 Apr 2003 09:31:25 -0700 (PDT) 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 h37GVNrl015380 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Apr 2003 09:31:26 -0700 Message-ID: <3E91A7D2.7@Royer.com> Date: Mon, 07 Apr 2003 10:31:14 -0600 From: Doug Royer Reply-To: "<" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: How do you get the METHOD property on a SEARCH References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080602060300060005040009" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080602060300060005040009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: > I'm still a little confused. > On the query, I used an ID on the SEARCH command. > How do I match up multiple VCALENDAR objects to one SEARCH command > VCALENDAR object? If the original command contained 'ID=xxx' then they contain 'CMD;ID=xxx:REPLY'. In draft...-10: reply-cmd = replyparam ":" "REPLY" replyparam = *( ; The 'id' parameter value MUST BE exactly the ; same as the value sent in the original ; CMD property. If the original CMD did ; not have an 'id' parameter, then the 'id' ; MUST NOT be supplied in the REPLY. id-param ; the following is optional, ; and MAY occur more than once / other-params ) > How do I know there are multiple REPLY commands with the same ID? > How do I know when there won't be any more REPLY commands to the one > ID? It is valid ABNF to include multiple VCALENDAR objects as one MIME body part. It is specified in 2445. We have not modified that syntax. So, then can be in the same MIME body part Or: I for one do not see it as a problem to just keep reading until the end of the BEEP exchange. When the BEEP exchange is done, you have all of the replies. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080602060300060005040009 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDcxNjMxMTRaMCMGCSqGSIb3DQEJBDEWBBQT r3vjSVAvQT1ydRxr+sSKh6zZYDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWJX+8MBEAqI+ 83+0H7Wvr+Mp/bmhKJ97r6HerpzWjozOhGURg7UOd/76tu2ftiYz8/XHzhEBGuZ/SahtDBAy HRCqMS/HeaxSKtxMWG0wh7IRuI+0WXlxLLWG0w1Aa+kvUoS+mmzU9p/pFWIr4xoWA3JYwiJ+ ilyu7jDOS9vMnnVCC/9B78W9fMB/Q1qJ+S8o+wd1XLayqSpdtUHfdDZGwfoxLYZD8cJMsu83 KoefiIYBUH6rfNs24v8+5zim+0YLB3eZ6rQSvThD5bqoZG/Z8F5lqgZpr6k+kSzkk0Xao+ar 2bFS3gtp2KmDATpgjfXzMCkEUBO4BbY+AE3LgzUxJAAAAAAAAA== --------------ms080602060300060005040009-- From owner-ietf-calendar@mail.imc.org Mon Apr 7 13:26:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28384 for ; Mon, 7 Apr 2003 13:26:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37H96JM016285 for ; Mon, 7 Apr 2003 10:09:06 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37H96gW016284 for ietf-calendar-bks; Mon, 7 Apr 2003 10:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37H93JM016279 for ; Mon, 7 Apr 2003 10:09:04 -0700 (PDT) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Mon, 07 Apr 2003 10:56:22 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 07 Apr 2003 11:07:27 -0600 From: "Preston Stephenson" To: Subject: Re: How do you get the METHOD property on a SEARCH Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Thanks, I see where I went wrong. Some on the commands restrict the reply to only one VCALENDAR object. For example on the create, create-reply = "BEGIN" ":" "VCALENDAR" CRLF creply-props 1*(create-vreply) "END" ":" "VCALENDAR" CRLF It would be helpful to me if the documentation included explicit ABNF for the reply on each of the commands. Thanks. Preston >>> Doug@royer.com 4/7/2003 10:31:14 AM >>> Preston Stephenson wrote: > I'm still a little confused. > On the query, I used an ID on the SEARCH command. > How do I match up multiple VCALENDAR objects to one SEARCH command > VCALENDAR object? If the original command contained 'ID=xxx' then they contain 'CMD;ID=xxx:REPLY'. In draft...-10: reply-cmd = replyparam ":" "REPLY" replyparam = *( ; The 'id' parameter value MUST BE exactly the ; same as the value sent in the original ; CMD property. If the original CMD did ; not have an 'id' parameter, then the 'id' ; MUST NOT be supplied in the REPLY. id-param ; the following is optional, ; and MAY occur more than once / other-params ) > How do I know there are multiple REPLY commands with the same ID? > How do I know when there won't be any more REPLY commands to the one > ID? It is valid ABNF to include multiple VCALENDAR objects as one MIME body part. It is specified in 2445. We have not modified that syntax. So, then can be in the same MIME body part Or: I for one do not see it as a problem to just keep reading until the end of the BEEP exchange. When the BEEP exchange is done, you have all of the replies. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From subs-reminder@imc.org Mon Apr 7 13:42:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28874 for ; Mon, 7 Apr 2003 13:42:42 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HjBJM020717 for ; Mon, 7 Apr 2003 10:45:11 -0700 (PDT) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37HjBvF020716; Mon, 7 Apr 2003 10:45:11 -0700 (PDT) Date: Mon, 7 Apr 2003 10:45:11 -0700 (PDT) Message-Id: <200304071745.h37HjBvF020716@above.proper.com> To: calsch-archive@ietf.org Subject: [[935001237]] Subscription to ietf-calendar for calsch-archive@lists.ietf.org Greetings. This message is a periodic reminder that calsch-archive@lists.ietf.org is subscribed to the ietf-calendar mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "calsch-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Mon Apr 7 14:10:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29523 for ; Mon, 7 Apr 2003 14:10:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HwDJM023976 for ; Mon, 7 Apr 2003 10:58:13 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37HwDCm023975 for ietf-calendar-bks; Mon, 7 Apr 2003 10:58:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37HwCJM023968 for ; Mon, 7 Apr 2003 10:58:12 -0700 (PDT) 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 h37HwArl016111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Apr 2003 10:58:13 -0700 Message-ID: <3E91BC26.3050002@Royer.com> Date: Mon, 07 Apr 2003 11:57:58 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: How do you get the METHOD property on a SEARCH References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090207040904020002080104" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090207040904020002080104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks but bad example :-) Create would not return METHOD. However for SEARCH it does say (And only SEARCH would return METHOD properties from the stored objects): The data in each result contains an iCalendar object composed of all the selected components enclosed in a "VREPLY" component. Only "REQUEST-STATUS" property and the properties mentioned in the "SELECT" clause of the QUERY are included in the components. Each iCalendar object is tagged with the "TARGET" property. 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...). Preston Stephenson wrote: > Thanks, I see where I went wrong. > > Some on the commands restrict the reply to only one VCALENDAR object. > For example on the create, > create-reply = "BEGIN" ":" "VCALENDAR" CRLF > creply-props > 1*(create-vreply) > "END" ":" "VCALENDAR" CRLF > > It would be helpful to me if the documentation included explicit ABNF > for the reply on each of the commands. For SEARCH it can be just about anything. > Thanks. > Preston > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090207040904020002080104 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDcxNzU3NThaMCMGCSqGSIb3DQEJBDEWBBQW aNANI0//VoUP+JH0mHQ5bV0ziTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEArA4wB/SRnzAF E0UYjLHcus7ZihknNVrp1RkBRHzflMWOmfrVS2l2Ap2ZA+/8EWDNiDQAnqjmDda7p3I6Aaw6 m59qU60fu94CzOUqSUK66NoezaMNdIzgPl0dLFfDkwTOGjLp6Q4M5mXzu7lKkX3mdi+KOttD YZ8dIDjvsg4DWfb5feGFkTVn533kVe0EnrUOoE47QJmDijaWY3u0vNj6/88ZCMBjGaNHsge2 yyC1Ex1J8APCTZsgO1VH5P8uX0M9yUW+ysSW+aZwl1tQXB1vgvlaTonrvAxgiwtGci7yYPjm QCZq2zeer07p+l6R3qPj5V9Rq44GJtdUiqR3eNa3cwAAAAAAAA== --------------ms090207040904020002080104-- From owner-ietf-calendar@mail.imc.org Mon Apr 7 18:33:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09344 for ; Mon, 7 Apr 2003 18:33:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37MMhJM025606 for ; Mon, 7 Apr 2003 15:22:43 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37MMgkn025604 for ietf-calendar-bks; Mon, 7 Apr 2003 15:22:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37MMeJM025588 for ; Mon, 7 Apr 2003 15:22:40 -0700 (PDT) In-Reply-To: <3E91A41D.7040504@Royer.com> To: ietf-calendar@imc.org Subject: Re: How do you get the METHOD property on a SEARCH MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 7 Apr 2003 18:22:38 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/07/2003 06:22:26 PM, Serialize complete at 04/07/2003 06:22:26 PM Content-Type: multipart/alternative; boundary="=_alternative 007AD73385256D01_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007AD73385256D01_= Content-Type: text/plain; charset="US-ASCII" This may appear long but its because of the full sized examples. If you skip over them and just read the text initially its not so bad. Doug replied on 04/07/2003 12:15:25 PM: > > So you expect that the meta information in the _original_ containing > > VCALENDAR of the VEVENT would be copied in to the _response_ containing > > VCALENDAR?? > > > > Would that apply ONLY to METHOD or would/should that apply to ALL > > properties? Or did you forget that the QUERY was for VEVENTs and all > > their containing information and NOT for the VCALENDAR that the VEVENT > > was in which is where the METHOD property resides? > > As METHOD belongs in the VCALENDAR, Andrea's reply is exactly > what I was going to post. I think you missed the issue Preston pointed out so Ill try to show it graphically. If I send you an invitation it would look like: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Bruces CUAs prodid CMD:CREATE METHOD:REQUEST TARGET:PatsCalendar TARGET:DougsCalendar BEGIN:VEVENT ORGANIZER;CN=Bruce Kahn:cap:Bruce@widget.com ATTENDEE;CN=Bruce Kahn;PARTSTAT=Accepted:cap:Bruce@widget.com ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:Pat@widget.com ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:Doug@widget.com DTSTART:20030407T180000Z DTEND:20030407T190000Z UID:12345678@widget.com SUMMARY:Important Meeting on SEARCH Issue SEQUENCE:5 DTSTAMP:20030407T120000Z END:VEVENT END:VCALENDAR BTW: CAP says NOTHING about whether or not the entry is CREATEd with all the propeties sent or not so I assume that both Pat and Doug would get a copy like the playload above instead of some stripped down copy. So when Doug goes and uses his CUA to send the SEARCH to find the any 'unprocessed' entires he would use: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Dougs CUA's prodid CMD:SEARCH TARGET:DougsCalendar BEGIN:VQUERY QUERYID:Fetch new VEVENT messages QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' END:VQUERY END:VCALENDAR According to Andrea and Doug the response to the SEARCH command would be: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//The CSs prodid CMD:REPLY METHOD:REQUEST TARGET:DougsCalendar BEGIN:VREPLY REQUEST-STATUS:2.0 BEGIN:VEVENT ORGANIZER;CN=Bruce Kahn:cap:Bruce@widget.com Attendee;CN=Bruce Kahn;PARTSTAT=Accepted:cap:Bruce@widget.com ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:Pat@widget.com ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:Doug@widget.com DTSTART:20030407T180000Z DTEND:20030407T190000Z UID:12345678@widget.com SUMMARY:Important Meeting on SEARCH Issue SEQUENCE:5 DTSTAMP:20030407T120000Z END:VEVENT END:VREPLY END:VCALENDAR if I read them correctly. There are a couple problems in achieving this though: 1: The METHOD property returned is copied from the VCALENDAR part of REQUEST message. However it is NOT part of the VEVENT component; it is a property of the VEVENTs contaniner (the VCALENDAR component)! As such it is NOT SELECTable in the SEARCH command if you scope the query to "FROM VEVENT". The METHOD property data resides OUTSIDE the returned VEVENT and as such its not accessible given the rules in 6.1.1. CAL-QUERY Value Type. 2: Nowhere in CAP does it have prose that I read that indicates that some 'related' or 'meta' data is automagically selected and put into the response. That is, I found no prose that says the METHOD property is exempt from the rules and always copied into a SEARCH command response. 3: As John noted this quandry also applys to other components like a VTIMEZONE associated with the VEVENT. If I had sent: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Bruces CUAs prodid CMD:CREATE METHOD:REQUEST TARGET:PatsCalendar TARGET:DougsCalendar BEGIN:VTIMEZONE TZID:US-Eastern [snip, snip] END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Bruce Kahn:cap:Bruce@widget.com Attendee;CN=Bruce Kahn;PARTSTAT=Accepted:cap:Bruce@widget.com ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:Pat@widget.com ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:Doug@widget.com DTSTART;TZID=US-Eastern:20030407T130000 DTEND;TZID=US-Eastern:20030407T140000 UID:12345678@widget.com SUMMARY:Important Meeting on SEARCH Issue SEQUENCE:5 DTSTAMP:20030407T120000Z END:VEVENT END:VCALENDAR then just how would Dougs CUA be expected to get the VTIMEZONE data sent with my REQUEST? Would it also be magically included? Would this magic also apply to PRODID so Doug could see the requestors (ie: my) CUAs PRODID? What about other properties outside the VEVENT?? Where do we draw the invisible line??? Given the way we have defined the searching rules in 6.1.1 I think Preston found a real problem w/the searching mechanism. > > Um, the SELECT did not SELECT the contents of the VEVENTs outter > > VCALENDAR, just the contents of the VEVENT so unless there is some > > implicit "When you give me VEVENTs (or VTODOs, etc) then you also MUST > > return the other properties in the associated containing VCALENDAR" then > > what Preston asked for is not possible as CAP is currently written. > > Yes it is and I think that Andrea's response is the only viable solution. No it is not. Nowhere in 6.1.1 does it say that properties OUTSIDE of the scoped container are returned or even selectable! The METHOD property is part of the REQUESTs VCALENDAR, NOT part of the actual VEVENT. You are assuming that because I can "SELECT * FROM VEVENT" to get all the properties within the VEVENT that it also applys to properties "ABOVE" or "PEER" to the VEVENT. NOWHERE IN CAP DOES IT SAY THIS! > > I would expect that the _response_ VCALENDAR would contain new > > properties and NOT all the properties of the original VCALENDAR. > > What *exactly* do you expect? Given the rules from Section 6.1.1 I would expect NO METHOD property on the response! > Did you have another proposal? As you know the PRODID and VERSION > may also be supplied in the VCALENDAR reply even when they are not > part of the original query. You totally missed the point. All those properties are OUTSIDE the VEVENT what the QUERY is scoped to. As such they are NOT available in the response!! 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 007AD73385256D01_= Content-Type: text/html; charset="US-ASCII"
<CAUTION>
This may appear long but its because of the full sized examples.  If you skip over them and just read the text initially its not so bad.
</CAUTION>

Doug replied on 04/07/2003 12:15:25 PM:
> > So you expect that the meta information in the _original_ containing
> > VCALENDAR of the VEVENT would be copied in to the _response_ containing
> > VCALENDAR??
> >
> > Would that apply ONLY to METHOD or would/should that apply to ALL
> > properties?  Or did you forget that the QUERY was for VEVENTs and all
> > their containing information and NOT for the VCALENDAR that the VEVENT
> > was in which is where the METHOD property resides?
>
> As METHOD belongs in the VCALENDAR, Andrea's reply is exactly
> what I was going to post.
I think you missed the issue Preston pointed out so Ill try to show it graphically.  If I send you an invitation it would look like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Bruces CUAs prodid
CMD:CREATE
METHOD:REQUEST
TARGET:PatsCalendar
TARGET:DougsCalendar
BEGIN:VEVENT
ORGANIZER;CN=Bruce Kahn:cap:Bruce@widget.com
ATTENDEE;CN=Bruce Kahn;PARTSTAT=Accepted:cap:Bruce@widget.com
ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:Pat@widget.com
ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:Doug@widget.com
DTSTART:20030407T180000Z
DTEND:20030407T190000Z
UID:12345678@widget.com
SUMMARY:Important Meeting on SEARCH Issue
SEQUENCE:5
DTSTAMP:20030407T120000Z
END:VEVENT
END:VCALENDAR
BTW: CAP says NOTHING about whether or not the entry is CREATEd with all the propeties sent or not so I assume that both Pat and Doug would get a copy like the playload above instead of some stripped down copy.

So when Doug goes and uses his CUA to send the SEARCH to find the any 'unprocessed' entires he would use:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Dougs CUA's prodid
CMD:SEARCH
TARGET:DougsCalendar
BEGIN:VQUERY
QUERYID:Fetch new VEVENT messages
QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED'
END:VQUERY
END:VCALENDAR
According to Andrea and Doug the response to the SEARCH command would be:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//The CSs prodid
CMD:REPLY
METHOD:REQUEST
TARGET:DougsCalendar
BEGIN:VREPLY
REQUEST-STATUS:2.0
BEGIN:VEVENT
ORGANIZER;CN=Bruce Kahn:cap:Bruce@widget.com
Attendee;CN=Bruce Kahn;PARTSTAT=Accepted:cap:Bruce@widget.com
ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:Pat@widget.com
ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:Doug@widget.com
DTSTART:20030407T180000Z
DTEND:20030407T190000Z
UID:12345678@widget.com
SUMMARY:Important Meeting on SEARCH Issue
SEQUENCE:5
DTSTAMP:20030407T120000Z
END:VEVENT
END:VREPLY
END:VCALENDAR
if I read them correctly.  There are a couple problems in achieving this though:

1: The METHOD property returned is copied from the VCALENDAR part of REQUEST message.  However it is NOT part of the VEVENT component; it is a property of the VEVENTs contaniner (the VCALENDAR component)!  As such it is NOT SELECTable in the SEARCH command if you scope the query to "FROM VEVENT".  The METHOD property data resides OUTSIDE the returned VEVENT and as such its not accessible given the rules in 6.1.1. CAL-QUERY Value Type.

2: Nowhere in CAP does it have prose that I read that indicates that some 'related' or 'meta' data is automagically selected and put into the response.  That is, I found no prose that says the METHOD property is exempt from the rules and always copied into a SEARCH command response.

3: As John noted this quandry also applys to other components like a VTIMEZONE associated with the VEVENT.  If I had sent:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Bruces CUAs prodid
CMD:CREATE
METHOD:REQUEST
TARGET:PatsCalendar
TARGET:DougsCalendar
BEGIN:VTIMEZONE
TZID:US-Eastern
[snip, snip]
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Bruce Kahn:cap:Bruce@widget.com
Attendee;CN=Bruce Kahn;PARTSTAT=Accepted:cap:Bruce@widget.com
ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:Pat@widget.com
ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:Doug@widget.com
DTSTART;TZID=US-Eastern:20030407T130000
DTEND;TZID=US-Eastern:20030407T140000
UID:12345678@widget.com
SUMMARY:Important Meeting on SEARCH Issue
SEQUENCE:5
DTSTAMP:20030407T120000Z
END:VEVENT
END:VCALENDAR

then just how would Dougs CUA be expected to get the VTIMEZONE data sent with my REQUEST?  Would it also be magically included?  

Would this magic also apply to PRODID so Doug could see the requestors (ie: my) CUAs PRODID?  What about other properties outside the VEVENT??  Where do we draw the invisible line???

Given the way we have defined the searching rules in 6.1.1 I think Preston found a real problem w/the searching mechanism.

> > Um, the SELECT did not SELECT the contents of the VEVENTs outter
> > VCALENDAR, just the contents of the VEVENT so unless there is some
> > implicit "When you give me VEVENTs (or VTODOs, etc) then you also MUST
> > return the other properties in the associated containing VCALENDAR" then
> > what Preston asked for is not possible as CAP is currently written.
>
> Yes it is and I think that Andrea's response is the only viable solution.
No it is not.  Nowhere in 6.1.1 does it say that properties OUTSIDE of the scoped container are returned or even selectable!  The METHOD property is part of the REQUESTs VCALENDAR, NOT part of the actual VEVENT.  You are assuming that because I can "SELECT * FROM VEVENT" to get all the properties within the VEVENT that it also applys to properties "ABOVE" or "PEER" to the VEVENT.  NOWHERE IN CAP DOES IT SAY THIS!

> > I would expect that the _response_ VCALENDAR would contain new
> > properties and NOT all the properties of the original VCALENDAR.  
>
> What *exactly* do you expect?
Given the rules from Section 6.1.1 I would expect NO METHOD property on the response!

> Did you have another proposal? As you know the PRODID and VERSION
> may also be supplied in the VCALENDAR reply even when they are not
> part of the original query.
You totally missed the point.  All those properties are OUTSIDE the VEVENT what the QUERY is scoped to.  As such they are NOT available in the response!!

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 007AD73385256D01_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 7 19:11:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10380 for ; Mon, 7 Apr 2003 19:11:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37N1oJM003339 for ; Mon, 7 Apr 2003 16:01:50 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37N1of5003338 for ietf-calendar-bks; Mon, 7 Apr 2003 16:01:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h37N1nJM003334 for ; Mon, 7 Apr 2003 16:01:49 -0700 (PDT) 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 h37N1mrl019015 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Apr 2003 16:01:51 -0700 Message-ID: <3E920352.6040906@Royer.com> Date: Mon, 07 Apr 2003 17:01:38 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: How do you get the METHOD property on a SEARCH References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040101040500050702030108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040101040500050702030108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > I think you missed the issue Preston pointed out so Ill try to show it > graphically. If I send you an invitation it would look like: > > BTW: CAP says NOTHING about whether or not the entry is CREATEd with all > the propeties sent or not so I assume that both Pat and Doug would get a > copy like the playload above instead of some stripped down copy. "with all of the properties sent" - Why would you rip out any properties sent? > So when Doug goes and uses his CUA to send the SEARCH to find the any > 'unprocessed' entires he would use: > > QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' > According to Andrea and Doug the response to the SEARCH command would be: > ... > END:VCALENDAR > > if I read them correctly. There are a couple problems in achieving this > though: > > 1: The METHOD property returned is copied from the VCALENDAR part of > REQUEST message. However it is NOT part of the VEVENT component; it is > a property of the VEVENTs contaniner (the VCALENDAR component)! Yes. > As such > it is NOT SELECTable in the SEARCH command if you scope the query to > "FROM VEVENT". The METHOD property data resides OUTSIDE the returned > VEVENT and as such its not accessible given the rules in > 6.1.1. CAL-QUERY Value Type. So you are saying you do not want it fixed? If not do you have a problem doing it that way? Or do you have a proposal? > 2: Nowhere in CAP does it have prose that I read that indicates that > some 'related' or 'meta' data is automagically selected and put into the > response. That is, I found no prose that says the METHOD property is > exempt from the rules and always copied into a SEARCH command response. Which is why I responded that I'll update the text. Did not object to the proposal? Or did I miss your proposal? > 3: As John noted this quandry also applys to other components like a > VTIMEZONE associated with the VEVENT. If I had sent: > > ... > > then just how would Dougs CUA be expected to get the VTIMEZONE data sent > with my REQUEST? Would it also be magically included? Magic - no. Did you have another proposal? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040101040500050702030108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDcyMzAxMzhaMCMGCSqGSIb3DQEJBDEWBBRL hCDwsMdEvRQKzktCFwtEBBUbADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAMpfY291cOgAZ om044Urt7oLwCynwmhd2+8JAJwP7zO/DmgXq+Y73s8ZQVqMjmwY1XBvPHt9KDCwq2/9VkGiY NKIAj7szoW4M/YNsFDZRzsxQreyApE0suP8sL5C8xrSUAbr+eNQYUTb+hpBOhZ7uG8XniQpS Wg67hJXqnrpBiYC2NZt56L+cXEXMdHy6b6V1vlKdqzRAGVy6ETkqj6tBY2XIcfAQ4aTR/5LA XMC+xTHM9YusjSHz1+4rh/uZNh0kw2vRcE8nygIUOYJdB/Wf0lyaBjcDfRI4id4vlhnhgiAB zkgb0qWeEwLzWbOLJRcjJY2WmZDgKSAqTAm3iMSLQQAAAAAAAA== --------------ms040101040500050702030108-- From owner-ietf-calendar@mail.imc.org Tue Apr 8 01:33:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17516 for ; Tue, 8 Apr 2003 01:33:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h385PrJM019333 for ; Mon, 7 Apr 2003 22:25:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h385PrOh019332 for ietf-calendar-bks; Mon, 7 Apr 2003 22:25:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo 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.9/8.11.6) with ESMTP id h385PqJM019327 for ; Mon, 7 Apr 2003 22:25:52 -0700 (PDT) Received: (from slh@localhost) by bikini.cac.washington.edu (8.11.3/8.11.3) id h385TI314649 for ietf-calendar@imc.org; Mon, 7 Apr 2003 22:29:18 -0700 (PDT) Date: Mon, 7 Apr 2003 22:29:18 -0700 (PDT) Message-Id: <200304080529.h385TI314649@bikini.cac.washington.edu> To: ietf-calendar@imc.org Subject: cap-10 section 9. comments From: slh@cac.washington.edu Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (same format as previous, similar msgs) ---------------------------------------- [91;5044] agenda = "BEGIN" ":" "VAGENDA" CRLF agendaprop *(icalobject) ; as defined in [iCAL] ************* [ should this be ``icalbody'' (and no need for the repetion)? ] "END" ":" "VAGENDA" CRLF agendaprop = *( ; The following MUST occur exactly once. ; allow-conflict / calid / calscale / created / default-charset / default-locale / default-tzid / last-modified / ; The following MUST occur at least once. ; and the value MUST NOT be empty. / owner ; The following are optional, ; and MAY occur more than once. / name / related-to / other-props / x-comp ********* [ this is confusing having a component in something named *prop and unnecessary since it is included icalbody? ] ) ---------------------------------------- [92;5100] agendac = "BEGIN" ":" "VAGENDA" CRLF agendacprop *(icalobject) ; as defined in [iCAL] ************* [ should this be ``icalbody'' (and no need for the repetion)? ] "END" ":" "VAGENDA" CRLF agendacprop = *( ; The following MUST occur exactly once. ; allow-conflict / calid / calscale / default-charset / default-locale / default-tzid / ; The following MUST occur at least once. ; and the value MUST NOT be empty. ; / owner ; The following are optional, ; and MAY occur more than once. ; / name / related-to / other-props / x-comp ********* [ this is confusing having a component in something named *prop and unnecessary since it is included icalbody? ] ) ---------------------------------------- [93;5163] CALSCALE - A comma separated list of CALSCALEs supported by this CS. All "VAGENDA" component calendar CALSCALE properties MUST BE from this list. This list MUST contain at least "GREGORIAN". The default for newly created "VAGENDA" components is the first entry. ********************************************************************* [ need a subsection in section 8 to formally redefine CALSCALE? ] ---------------------------------------- [94;5212] calstorec = "BEGIN" ":" "VCALSTORE" CRLF calstoreprop *(vagendac) ******** [ this should be ``agenda''? (the vagenda/vagendac rule names are kind of inconsistent w/the other components too) ] "END" ":" "VCALSTORE" CRLF calstoreprop = *( ; the following MUST occur exactly once allow-conflict / calscale / calmaster / created / csid / default-charset / default-locale / default-vcars / default-tzid / last-modified ; the following are optional, ; and MAY occur more than once / name / related-to / other-props / x-comp ********* [ this is confusing having a component in something named *prop and unnecessary since it is included agenda? ] ) ---------------------------------------- [95;5272] carprop = 1*( ; 'carid' is REQUIRED, ; but MUST NOT occur more than once carid / ^ decreed ; the following are OPTIONAL, ; and MAY occur more than once name / other-props ) ---------------------------------------- [99;5496] queryc = "BEGIN" ":" "VQUERY" CRLF queryprop "END" ":" "VCAR" CRLF ----VQUERY ---------------------------------------- From owner-ietf-calendar@mail.imc.org Tue Apr 8 02:52:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00845 for ; Tue, 8 Apr 2003 02:52:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h386XBJM028358 for ; Mon, 7 Apr 2003 23:33:11 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h386XBPB028357 for ietf-calendar-bks; Mon, 7 Apr 2003 23:33:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h386X9JM028352 for ; Mon, 7 Apr 2003 23:33:09 -0700 (PDT) Received: from [::ffff:194.185.205.182] by hal-5.inet.it via I-SMTP-4.3.7-430 id ::ffff:194.185.205.182+7KQsgg7g2; Tue, 08 Apr 2003 08:33:03 +0200 Date: Tue, 8 Apr 2003 08:33:01 +0200 Subject: Re: How do you get the METHOD property on a SEARCH Content-Type: multipart/alternative; boundary=Apple-Mail-2-609420923 Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-calendar@imc.org To: Bruce_Kahn@notesdev.ibm.com From: Andrea Campi In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-2-609420923 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I feel I already replied to most of your point so I'll just cover the=20 one related to VTIMEZONE. On Tuesday, April 8, 2003, at 12:22 AM, Bruce_Kahn@notesdev.ibm.com=20 wrote: > 3: As John noted this quandry also applys to other components like a=20= > VTIMEZONE associated with the VEVENT. =A0If I had sent: > > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:-//Bruces CUAs prodid > CMD:CREATE > METHOD:REQUEST > TARGET:PatsCalendar > TARGET:DougsCalendar > BEGIN:VTIMEZONE > TZID:US-Eastern > [snip, snip] > END:VTIMEZONE > BEGIN:VEVENT > ORGANIZER;CN=3DBruce Kahn:cap:Bruce@widget.com > Attendee;CN=3DBruce Kahn;PARTSTAT=3DAccepted:cap:Bruce@widget.com > ATTENDEE;CN=3DPat Egen;PARTSTAT=3DNeeds-Action:cap:Pat@widget.com > ATTENDEE;CN=3DDoug Royer;PARTSTAT=3DNeeds-Action:cap:Doug@widget.com > DTSTART;TZID=3DUS-Eastern:20030407T130000 > DTEND;TZID=3DUS-Eastern:20030407T140000 > UID:12345678@widget.com > SUMMARY:Important Meeting on SEARCH Issue > SEQUENCE:5 > DTSTAMP:20030407T120000Z > END:VEVENT > END:VCALENDAR > > then just how would Dougs CUA be expected to get the VTIMEZONE data=20 > sent with my REQUEST? =A0Would it also be magically included? =A0 Actually, I do expect VTIMEZONE to also be in the reply, yes. That's=20 been a requirement ever since RFC2445. Note that a few months ago I=20 asked exactly the same question (didn't sound sane to me to assume this=20= much) and even proposed to make it an optional behavior. However,=20 violating RFC2445 is not an option - and skipping VTIMEZONE in the=20 reply would violate it. Bye, Andrea= --Apple-Mail-2-609420923 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I feel I already replied to most of your point so I'll just cover the one related to VTIMEZONE. On Tuesday, April 8, 2003, at 12:22 AM, Bruce_Kahn@notesdev.ibm.com wrote: 3: As John noted this quandry also applys to other components like a VTIMEZONE associated with the VEVENT. =A0If I had = sent: BEGIN:VCALENDAR 3333,3333,3333VERSION:2.0 PRODID:-//Bruces CUAs prodid CMD:CREATE METHOD:REQUEST TARGET:PatsCalendar TARGET:DougsCalendar BEGIN:VTIMEZONE TZID:US-Eastern [snip, snip] END:VTIMEZONE 3333,3333,3333BEGIN:VEVENT ORGANIZER;CN=3DBruce Kahn:cap:Bruce@widget.com Attendee;CN=3DBruce Kahn;PARTSTAT=3DAccepted:cap:Bruce@widget.com ATTENDEE;CN=3DPat Egen;PARTSTAT=3DNeeds-Action:cap:Pat@widget.com ATTENDEE;CN=3DDoug Royer;PARTSTAT=3DNeeds-Action:cap:Doug@widget.com = DTSTART;TZID=3DUS-Eastern3333,3333,3333:2003= 0407T130000 = DTEND;TZID=3DUS-Eastern:3333,3333,3333200304= 07T140000 UID:12345678@widget.com SUMMARY:Important Meeting on SEARCH Issue SEQUENCE:5 DTSTAMP:20030407T120000Z END:VEVENT END:VCALENDAR 3333,3333,3333then just how would Dougs CUA be expected to get the VTIMEZONE data sent with my REQUEST? =A0Would it also be magically included? =A0 Actually, I do expect VTIMEZONE to also be in the reply, yes. That's been a requirement ever since RFC2445. Note that a few months ago I asked exactly the same question (didn't sound sane to me to assume this much) and even proposed to make it an optional behavior. However, violating RFC2445 is not an option - and skipping VTIMEZONE in the reply would violate it. Bye, Andrea= --Apple-Mail-2-609420923-- From owner-ietf-calendar@mail.imc.org Tue Apr 8 03:21:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01226 for ; Tue, 8 Apr 2003 03:21:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h387F2JM006316 for ; Tue, 8 Apr 2003 00:15:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h387F29h006315 for ietf-calendar-bks; Tue, 8 Apr 2003 00:15:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h387F0JM006302 for ; Tue, 8 Apr 2003 00:15:01 -0700 (PDT) Received: from [::ffff:194.185.205.182] by hal-5.inet.it via I-SMTP-4.3.7-430 id ::ffff:194.185.205.182+jmHTXUtcw; Tue, 08 Apr 2003 09:14:59 +0200 Date: Tue, 8 Apr 2003 09:14:53 +0200 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: Fwd: How do you get the METHOD property on a SEARCH From: Andrea Campi To: ietf-calendar@imc.org Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h387F2JM006311 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I just noticed that I mistakenly had sent the following to Bruce only. Bye, Andrea Begin forwarded message: > From: Andrea Campi > Date: Mon Apr 7, 2003 11:25:52 PM Europe/Rome > To: Bruce_Kahn@notesdev.ibm.com > Subject: Re: How do you get the METHOD property on a SEARCH > > Hi Bruce, > > On Monday, April 7, 2003, at 04:21 PM, Bruce_Kahn@notesdev.ibm.com > wrote: >> Andrea wrote on 04/07/2003 04:48:31 AM: >> > This query looks appropriate to me, yes. I'd expect the CAP to >> > reply with something like: >> > >> > BEGIN:VCALENDAR >> > METHOD:REQUEST >> > BEGIN:VREPLY >> > BEGIN:VEVENT >> >> So you expect that the meta information in the _original_ containing >> VCALENDAR of the VEVENT would be copied in to the _response_ >> containing VCALENDAR?? >> >> Would that apply ONLY to METHOD or would/should that apply to ALL >> properties?  Or did you forget that the QUERY was for VEVENTs and all >> their containing information and NOT for the VCALENDAR that the >> VEVENT was in which is where the METHOD property resides? > > Well, I'd expect the VCALENDAR to contain: > > PRODID and VERSION as stated by RFC2445 > METHOD as stated by RFC2446 > CMD and TARGET as stated by draft CAP > > After all, a reply containing unprocessed components wouldn't be valid > iTIP without corresponding METHOD properties, would it? > >> >> > So you have all the information you need; it's your choice how to >> > keep that information around. >> >> Um, the SELECT did not SELECT the contents of the VEVENTs outter >> VCALENDAR, just the contents of the VEVENT so unless there is some >> implicit "When you give me VEVENTs (or VTODOs, etc) then you also >> MUST return the other properties in the associated containing >> VCALENDAR" then what Preston asked for is not possible as CAP is >> currently written. >> I would expect that the _response_ VCALENDAR would contain new >> properties and NOT all the properties of the original VCALENDAR.   > > On the contrary, it sounds to me the above assumption is implicit in > iTIP. CAP doesn't state how exactly are you supposed to store the > METHOD for each VEVENT, but I'm sure that when you try to read them > back again you want to retrieve the original METHOD. To do this, I see > no other way then use iTIP. > > My view on this is that the METHOD property is sort of an additional > property of the VEVENT which happens to be transmitted in a special > way. In other words: I'm not sending the METHOD from the original > VCALENDAR, I'm grouping the resulting VEVENTs and synthesizing the > enclosing VCALENDAR(s). > >> Also, would this apply to all types of objects or just to the core >> VEVENT/VTODO/VJOURNAL/VTIMEZONE/etc type ones?  For example, would >> the information of a containing VEVENT be automatically >> copied/inserted when my CUA queries for VALARMs that TRIGGER in the >> next 10 minutes?  It MAY be necessary to know something from the >> containing > component... > > Now that's a good question. However, I'd say that's for (a future > update to) iTIP to answer, as we're doing nothing more than applying > iTIP here? > > > Let me add that I do share your worries on these items, as I'm sure > I've mentioned before; it all sounds tricky and hard to digest. > However, over the months I reached the conclusion that there's a sense > after all (not that I'd doubted it, with all the smart guys who've > been working on this); but I still think we could use some more > examples, especially non-trivial ones. > > Bye, > Andrea From owner-ietf-calendar@mail.imc.org Tue Apr 8 19:25:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08089 for ; Tue, 8 Apr 2003 19:25:04 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NEsJM023226 for ; Tue, 8 Apr 2003 16:14:54 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38NEsC1023225 for ietf-calendar-bks; Tue, 8 Apr 2003 16:14:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NEqJM023221 for ; Tue, 8 Apr 2003 16:14:53 -0700 (PDT) In-Reply-To: <3E920352.6040906@Royer.com> To: ietf-calendar@imc.org Subject: Re: How do you get the METHOD property on a SEARCH MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 8 Apr 2003 18:49:38 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/08/2003 07:14:57 PM, Serialize complete at 04/08/2003 07:14:57 PM Content-Type: multipart/alternative; boundary="=_alternative 007D48D085256D02_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D48D085256D02_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 04/07/2003 07:01:38 PM: > > 1: The METHOD property returned is copied from the VCALENDAR part of > > REQUEST message. However it is NOT part of the VEVENT component; it is > > a property of the VEVENTs contaniner (the VCALENDAR component)! > > Yes. And violating the rules of scoping is NOT good... Even more so if its contrary to the draft!! > > As such > > it is NOT SELECTable in the SEARCH command if you scope the query to > > "FROM VEVENT". The METHOD property data resides OUTSIDE the returned > > VEVENT and as such its not accessible given the rules in > > 6.1.1. CAL-QUERY Value Type. > > So you are saying you do not want it fixed? Im saying that your answer was incorrect given the current CAP text. If we want this behaviour then we have to clearly specify it (and thus we will need to change the text for CAL-QUERY) And of course I want the protocol fixed (Im not the one who wants thinks its ready for Last Call and this just confirms it). To me it was sounding as if you and Andrea did not think it was broken. > > 2: Nowhere in CAP does it have prose that I read that indicates that > > some 'related' or 'meta' data is automagically selected and put into the > > response. That is, I found no prose that says the METHOD property is > > exempt from the rules and always copied into a SEARCH command response. > > Which is why I responded that I'll update the text. I did not see any proposal, merely your answer that doing this violation of scoping was how it would work in your view. As Preston noted originally its NOT in CAP and thus needs fixing! > Did not object > to the proposal? Hmm, let me reread just your bits in your last message since I must have missed them the first time around: As METHOD belongs in the VCALENDAR, Andrea's reply is exactly what I was going to post. Umm, nope, nothing there. Yes it is and I think that Andrea's response is the only viable solution. If you provide a query that returns multiple METHOD values, just reply with multiple VALENDARs. Err, not yet... What *exactly* do you expect? Nah, thats not one... Did you have another proposal? As you know the PRODID and VERSION may also be supplied in the VCALENDAR reply even when they are not part of the original query. Hmm, thats all the bits you wrote last time and I dont see any actual proposal there. Merely responses to the effect that "Thats how I expect it to work" rather than "We need to add prose to CAP to codify this!" If I take them as some form of oddly worded proposal then I have some questions still: Would this "all inclusive" reponse now include all super-container data in it or just merely some selective set? That is, if I were to search "SELECT * FROM VALARM..." would/should I expect to get the original container structure back, like: BEGIN:VCALENDAR ... BEGIN:VEVENT ... BEGIN:VALARM ... END:VALARM END:VEVENT END:VCALENDAR or just the contents of the immediate container its in (ie: just the VEVENT and all its properties)? Would this inclusion of 'external to the component' data be all inclusive or just selective? That is, for the VEVENT case would it include ALL of the data in the containing VCALENDAR it came in or just some of it? Would "including all" mean all other components except those of the same container type (ie: if I sent 2 VEVENTs in 1 VCALENDAR, would you want/expect the 2nd VEVENT if the WHERE clause did NOT match because I searched by UID!) or is it the entire contents of the VCALENDAR object? If the data included from the container object was some partial subset of the original data then just how would the CUA get to the rest of it (or even could it)? Who decides which bits are copied and which are left out? > Or did I miss your proposal? You did not miss my own proposal because I did not present one. I merely pointed out that Preston did indeed find a valid problem w/the way CAP is written compared to the expectations of some on how it should work. I did however miss yours... > Magic - no. Did you have another proposal? Another? I have yet to see any first proposal. Dazzle 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 007D48D085256D02_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 04/07/2003 07:01:38 PM:
> > 1: The METHOD property returned is copied from the VCALENDAR part of
> > REQUEST message.  However it is NOT part of the VEVENT component; it is
> > a property of the VEVENTs contaniner (the VCALENDAR component)!
>
> Yes.
And violating the rules of scoping is NOT good...  Even more so if its contrary to the draft!!

>  >   As such
> > it is NOT SELECTable in the SEARCH command if you scope the query to
> > "FROM VEVENT".  The METHOD property data resides OUTSIDE the returned
> > VEVENT and as such its not accessible given the rules in
> > 6.1.1. CAL-QUERY Value Type.
>
> So you are saying you do not want it fixed?

Im saying that your answer was incorrect given the current CAP text.  If we want this behaviour then we have to clearly specify it (and thus we will need to change the text for CAL-QUERY)

And of course I want the protocol fixed (Im not the one who wants thinks its ready for Last Call and this just confirms it).  To me it was sounding as if you and Andrea did not think it was broken.

> > 2: Nowhere in CAP does it have prose that I read that indicates that
> > some 'related' or 'meta' data is automagically selected and put into the
> > response.  That is, I found no prose that says the METHOD property is
> > exempt from the rules and always copied into a SEARCH command response.
>
> Which is why I responded that I'll update the text.

I did not see any proposal, merely your answer that doing this violation of scoping was how it would work in your view.  As Preston noted originally its NOT in CAP and thus needs fixing!

>                                                     Did not object
> to the proposal?

Hmm, let me reread just your bits in your last message since I must have missed them the first time around:

As METHOD belongs in the VCALENDAR, Andrea's reply is exactly
what I was going to post.
Umm, nope, nothing there.

Yes it is and I think that Andrea's response is the only viable solution.
If you provide a query that returns multiple METHOD values, just reply
with multiple VALENDARs.
Err, not yet...

What *exactly* do you expect?
Nah, thats not one...

Did you have another proposal? As you know the PRODID and VERSION
may also be supplied in the VCALENDAR reply even when they are not
part of the original query.
Hmm, thats all the bits you wrote last time and I dont see any actual proposal there.  Merely responses to the effect that "Thats how I expect it to work" rather than "We need to add prose to CAP to codify this!"

If I take them as some form of oddly worded proposal then I have some questions still:

Would this "all inclusive" reponse now include all super-container data in it or just merely some selective set?  That is, if I were to search "SELECT * FROM VALARM..." would/should I expect to get the original container structure back, like:

BEGIN:VCALENDAR
...
BEGIN:VEVENT
...
BEGIN:VALARM
...
END:VALARM
END:VEVENT
END:VCALENDAR

or just the contents of the immediate container its in (ie: just the VEVENT and all its properties)?  

Would this inclusion of 'external to the component' data be all inclusive or just selective?  That is, for the VEVENT case would it include ALL of the data in the containing VCALENDAR it came in or just some of it?  

Would "including all" mean all other components except those of the same container type (ie: if I sent 2 VEVENTs in 1 VCALENDAR, would you want/expect the 2nd VEVENT if the WHERE clause did NOT match because I searched by UID!) or is it the entire contents of the VCALENDAR object?

If the data included from the container object was some partial subset of the original data then just how would the CUA get to the rest of it (or even could it)?  Who decides which bits are copied and which are left out?

>                           Or did I miss your proposal?

You did not miss my own proposal because I did not present one.  I merely pointed out that Preston did indeed find a valid problem w/the way CAP is written compared to the expectations of some on how it should work.  I did however miss yours...

> Magic - no. Did you have another proposal?
Another?  I have yet to see any first proposal.  Dazzle 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 007D48D085256D02_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 8 20:14:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09177 for ; Tue, 8 Apr 2003 20:13:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NjRJM025772 for ; Tue, 8 Apr 2003 16:45:27 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h38NjRnn025770 for ietf-calendar-bks; Tue, 8 Apr 2003 16:45:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h38NjMJM025755 for ; Tue, 8 Apr 2003 16:45:25 -0700 (PDT) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: How do you get the METHOD property on a SEARCH MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 8 Apr 2003 19:22:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 04/08/2003 07:45:27 PM, Serialize complete at 04/08/2003 07:45:27 PM Content-Type: multipart/alternative; boundary="=_alternative 008042A985256D02_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 008042A985256D02_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 04/08/2003 02:33:01 AM: > > then just how would Dougs CUA be expected to get the VTIMEZONE data > > sent with my REQUEST? Would it also be magically included? > > Actually, I do expect VTIMEZONE to also be in the reply, yes. That's > been a requirement ever since RFC2445. Yes it is but that has no bearing on the CAP draft for accessing / searching. There is NO mandate in 2445 on how CAP MUST or MUST NOT return data. A payload in CAP can be a fragment of the entire entry, at least thats valid according to the ABNF and prose under 6.1.1. The text in 6.1.1 NEVER describes the kind of scoping violations you suggested. In fact they uniformly show the contrary! The first example shows that a returned VALARM is NOT bundled inside its containing VEVENT even though to properly fire the VALARM needs info from that containing VEVENT. Even the text below has NO mention of returning properties of the super-container: (e) Selects all properties and all contained components in all "VEVENT" components that have a "VALARM" component with a "TRIGGER" property value between the provided dates and times. The text puts limits the scoping. There is nothing in the ABNF that indicates that properties/parameters from the containing object of the scoped object are even accessible, let alone returned. I realize that what you replied is how you expect CAP to function but thats NOT how its specified. > Note that a few months ago I > asked exactly the same question (didn't sound sane to me to assume this > much) and even proposed to make it an optional behavior. I was heads down for product end game for a couple months so I did not see your posting or the proposal. Can you tell me at least the thread subject? Also, did the WG pay any attention then? > However, > violating RFC2445 is not an option - and skipping VTIMEZONE in the > reply would violate it. Im a little on the fence WRT applying stict 2445/2446 requirements for the SEARCH command. Here is why: If the requesting CUA wanted all the info it should ask for it. In the VALARM example case in CAP: SELECT VALARM FROM VEVENT WHERE UID = "123" [snip] As there is no '.' (dot) in the VALARM after the SELECT above: BEGIN:VALARM TRIGGER;RELATED=END:PT5M REPEAT:4 ... END:VALARM BEGIN:VALARM TRIGGER;RELATED=START:PT5M DURATION:PT10M ... END:VALARM the CUA clearly knows what it is looking for and only wants some partial information back. However in order to properly fire the 'relative' alarms it MUST get the DTSTART (or DTEND) of the containing VEVENT so it SHOULD have requested "SELECT DTSTART,VALARM FROM VEVENT WHERE UID = "123"" so that it could properly fire the alarms. The CUA could have done the SEARCH in order to determine something about the alarms rather than try to fire them. A CUA may want to do some kind of pared down SEARCH where it gets only partial info for its own use and as such the CS and CAP have no business coercing the data returned in the SEARCH. Now, NONE of this "allowance" to ignore 2445/2446 is applied on the other commands; JUST on the SEARCH command as its NOT part of workflow or strict PIM work, it has other uses/needs. However this is a digression from the original point. I need to go get some food so Ill have to find your other reply later... 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 008042A985256D02_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 04/08/2003 02:33:01 AM:
> > then just how would Dougs CUA be expected to get the VTIMEZONE data
> > sent with my REQUEST?  Would it also be magically included?  
>
> Actually, I do expect VTIMEZONE to also be in the reply, yes. That's
> been a requirement ever since RFC2445.

Yes it is but that has no bearing on the CAP draft for accessing / searching.  There is NO mandate in 2445 on how CAP MUST or MUST NOT return data.  A payload in CAP can be a fragment of the entire entry, at least thats valid according to the ABNF and prose under 6.1.1.

The text in 6.1.1 NEVER describes the kind of scoping violations you suggested.  In fact they uniformly show the contrary!  The first example shows that a returned VALARM is NOT bundled inside its containing VEVENT even though to properly fire the VALARM needs info from that containing VEVENT.  Even the text below has NO mention of returning properties of the super-container:

    (e) Selects all properties and all contained
                components in all "VEVENT" components that have a "VALARM"
                component with a "TRIGGER" property value between
                the provided dates and times.
The text puts limits the scoping.  There is nothing in the ABNF that indicates that properties/parameters from the containing object of the scoped object are even accessible, let alone returned.   I realize that what you replied is how you expect CAP to function but thats NOT how its specified.

>                                          Note that a few months ago I
> asked exactly the same question (didn't sound sane to me to assume this
> much) and even proposed to make it an optional behavior.

I was heads down for product end game for a couple months so I did not see your posting or the proposal.  Can you tell me at least the thread subject?  Also, did the WG pay any attention then?

>                                                            However,
> violating RFC2445 is not an option - and skipping VTIMEZONE in the
> reply would violate it.
Im a little on the fence WRT applying stict 2445/2446 requirements for the SEARCH command.  Here is why:  If the requesting CUA wanted all the info it should ask for it.  In the VALARM example case in CAP:

SELECT VALARM FROM VEVENT WHERE UID = "123"
[snip]
As there is no '.' (dot) in the VALARM after the SELECT above:

BEGIN:VALARM
TRIGGER;RELATED=END:PT5M
REPEAT:4
...      
END:VALARM
BEGIN:VALARM
TRIGGER;RELATED=START:PT5M
DURATION:PT10M
...
END:VALARM
the CUA clearly knows what it is looking for and only wants some partial information back.  However in order to properly fire the 'relative' alarms it MUST get the DTSTART (or DTEND) of the containing VEVENT so it SHOULD have requested "SELECT DTSTART,VALARM FROM VEVENT WHERE UID = "123"" so that it could properly fire the alarms.  

The CUA could have done the SEARCH in order to determine something about the alarms rather than try to fire them.  A CUA may want to do some kind of pared down SEARCH where it gets only partial info for its own use and as such the CS and CAP have no business coercing the data returned in the SEARCH.  

Now, NONE of this "allowance" to ignore 2445/2446 is applied on the other commands; JUST on the SEARCH command as its NOT part of workflow or strict PIM work, it has other uses/needs.  However this is a digression from the original point.  I need to go get some food so Ill have to find your other reply later...

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 008042A985256D02_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 15 11:45:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01961 for ; Tue, 15 Apr 2003 11:45:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FFRBt2068770 for ; Tue, 15 Apr 2003 08:27:11 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FFRBjR068769 for ietf-calendar-bks; Tue, 15 Apr 2003 08:27:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FFR9t3068755 for ; Tue, 15 Apr 2003 08:27:10 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <0AE5DEE0-EC20-11D6-A80F-003065A8EEFC@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 15 Apr 2003 11:23:12 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/15/2003 11:27:08 AM, Serialize complete at 04/15/2003 11:27:08 AM Content-Type: multipart/alternative; boundary="=_alternative 00546AD285256D09_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00546AD285256D09_= Content-Type: text/plain; charset="US-ASCII" [Tried to send this before but it seems to evaporate and not get sent. Pardon me if its a duplicate. -BK] Andrea replied on 10/30/2002 10:55:41 AM: > Uhm... now I'm curious... How exactly do you design forward > compatibility in a protocol if you don't assume that "if a party > doesn't specify a later revision, we must assume it only supports an > earlier, known revision"? Note that I said _the default_. (I dont see 'default' in your question but Ill insert it accordingly) Actually to solve this you do NOT allow for defaulting of some values based on another AND still mandate a '1' instance in the ABNF. That is you do not allow, say, COMPONENTS to just default to "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,VEVENT,VALARM,VTIMEZONE" if CAP-VERSION:1.0 is and the property MUST be sent anyway. That approach is kind of mixed up. The current approach is half in one camp, half in another and doesnt serve either well. If we intend CAP-VERSION to be used to detect defaults then it SHOULD be acceptable to allow the default to be used in both directions. That is, a CS should be able to send just CAP-VERSION:1.0 if it implements all the defaults defined by CAP 1.0. The CS should only send a non-default value if it does not support the defaults. For example, no RRULE support would be indicated by sending "RECUR-ACCEPTED:FALSE" but if the CS supports RRULEs then NO RECUR-ACCEPTED need be sent. Put another way: If 'defaults' have to be expressly sent then what good are they?? Two options come to mind. Using CAP-VERSION and default values one sidedly is poor design because its both verbose and superfluous as well as an accident waiting to happen. I see 2 possible choices to correct this: Alternative #1: We should either use CAP-VERSION to _always_ imply defaults and only send non-default indicators. For cases where CAP-VERSIONs are unknown (ie: a CAP 1.0 CUA and a CAP 2.0 CS) then there needs to be some way to request the full list (defaults included!) from either side. This should only be necessary for the case of the 'older' side since 'newer' implementations should have no problem keeping track of the 'older' settings since they've already been published so are pre-existing and can easily be stored in some internal table. Alternative #2: We do not rely on CAP-VERISON to do setting defaulting/detection; it is merely informational or used to detect if both sides are able to properly communicate. Its used strictly for protocol compatability checking (ie: CAP-VERSION:2.0;2.0 would tell a CAP-VERSION:1.0 CUA that it cannot safely speak CAP to this CS). All values that can be returned are returned, including default values. This is much like the current role the CS has in the 09-b draft. After all, CAP-VERSION is described as "Version of CAP" but we are using it as a settings default controler instead of as the means by which two different versions of a protocol can detect if they are compatible or not. Im kind of partial to Alternative #2 but there may be other alternatives I have not considered. Im open to other suggestions... > Coincidentally, that's how HTTP works - if a client doesn't specify an > HTTP version, the server assumes it can only do 1.0 (well, apart from > kludges). I hate kludges especially in a protocol. They become the bane of our collective existance and something that hinder rather than help when a proper solution is sought. In HTTP there is no convenient way for one side to accurately tell what abilities the other has w/o doing some 'blind probing" (ie: "Can the server return byte ranges for this URL? Ill ask for it but I may or may not get back just what I want..."). This is why we have explicit properties to be returned on the GET-CAPABILITY command, even with 'default' values; no need to guess or infer. 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 00546AD285256D09_= Content-Type: text/html; charset="US-ASCII"
[Tried to send this before but it seems to evaporate and not get sent. Pardon me if its a duplicate. -BK]

Andrea replied on 10/30/2002 10:55:41 AM:
> Uhm... now I'm curious... How exactly do you design forward
> compatibility in a protocol if you don't assume that "if a party
> doesn't specify a later revision, we must assume it only supports an
> earlier, known revision"? Note that I said _the default_.
(I dont see 'default' in your question but Ill insert it accordingly)  Actually to solve this you do NOT allow for defaulting of some values based on another AND still mandate a '1' instance in the ABNF.  That is you do not allow, say, COMPONENTS to just default to "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,VEVENT,VALARM,VTIMEZONE" if CAP-VERSION:1.0 is and the property MUST be sent anyway.  That approach is kind of mixed up.  The current approach is half in one camp, half in another and doesnt serve either well.

If we intend CAP-VERSION to be used to detect defaults then it SHOULD be acceptable to allow the default to be used in both directions.  That is, a CS should be able to send just CAP-VERSION:1.0 if it implements all the defaults defined by CAP 1.0.  The CS should only send a non-default value if it does not support the defaults.  For example, no RRULE support would be indicated by sending "RECUR-ACCEPTED:FALSE" but if the CS supports RRULEs then NO RECUR-ACCEPTED need be sent.  Put another way: If 'defaults' have to be expressly sent then what good are they??

Two options come to mind.  Using CAP-VERSION and default values one sidedly is poor design because its both verbose and superfluous as well as an accident waiting to happen.   I see 2 possible choices to correct this:

Alternative #1: We should either use CAP-VERSION to _always_ imply defaults and only send non-default indicators.  For cases where CAP-VERSIONs are unknown (ie: a CAP 1.0 CUA and a CAP 2.0 CS) then there needs to be some way to request the full list (defaults included!) from either side.  This should only be necessary for the case of the 'older' side since 'newer' implementations should have no problem keeping track of the 'older' settings since they've already been published so are pre-existing and can easily be stored in some internal table.

Alternative #2: We do not rely on CAP-VERISON to do setting defaulting/detection; it is merely informational or used to detect if both sides are able to properly communicate.  Its used strictly for protocol compatability checking (ie: CAP-VERSION:2.0;2.0 would tell a CAP-VERSION:1.0 CUA that it cannot safely speak CAP to this CS).  All values that can be returned are returned, including default values.  This is much like the current role the CS has in the 09-b draft.  After all, CAP-VERSION is described as "Version of CAP" but we are using it as a settings default controler instead of as the means by which two different versions of a protocol can detect if they are compatible or not.

Im kind of partial to Alternative #2 but there may be other alternatives I have not considered.  Im open to other suggestions...

> Coincidentally, that's how HTTP works - if a client doesn't specify an
> HTTP version, the server assumes it can only do 1.0 (well, apart from
> kludges).
I hate kludges especially in a protocol.  They become the bane of our collective existance and something that hinder rather than help when a proper solution is sought.  

In HTTP there is no convenient way for one side to accurately tell what abilities the other has w/o doing some 'blind probing" (ie: "Can the server return byte ranges for this URL?  Ill ask for it but I may or may not get back just what I want...").  This is why we have explicit properties to be returned on the GET-CAPABILITY command, even with 'default' values; no need to guess or infer.

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 00546AD285256D09_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 15 11:48:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02149 for ; Tue, 15 Apr 2003 11:48:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FFRAt2068764 for ; Tue, 15 Apr 2003 08:27:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3FFRA6n068762 for ietf-calendar-bks; Tue, 15 Apr 2003 08:27:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3FFR9t2068755 for ; Tue, 15 Apr 2003 08:27:10 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <3DD91C19.4000903@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP ABNF and external references MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04022003NP April 02, 2003 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 15 Apr 2003 11:22:17 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/15/2003 11:27:08 AM, Serialize complete at 04/15/2003 11:27:08 AM Content-Type: multipart/alternative; boundary="=_alternative 0054551E85256D09_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054551E85256D09_= Content-Type: text/plain; charset="US-ASCII" Hmm, not sure why this was stuck in my laptops outgoing queue. Sorry its a bit dated (I queued it in Nov 2002) but its still relevant I think... Doug replied on 11/18/2002 11:58:01 AM: > > Im sorry I wasnt a bit more clear in my original posting; this change is > > probably not sufficient. The definition/ABNF for integer in RFC 2445 is: > > > > integer = (["+"] / "-") 1*DIGIT > > > > Description: If the property permits, multiple "integer" values are > > specified by a COMMA character (US-ASCII decimal 44) separated list > > of values. The valid range for "integer" is -2147483648 to > > 2147483647. If the sign is not specified, then the value is assumed > > to be positive. > > > > As such it is valid to have negative or "0" LATENCY. I think CAP should > > adopt the BEEP approach of expressly defining a range of allowed values > > ala: > > And how does a positive integer like the following that I > sent go negative? > > > p-integer = 1*DIGIT ; Where DIGIT is defined in [iCAL] You misread my posting. I was referring to the current integer ABNF. Your new ABNF does not allow negative numbers but it still allows for a latency of 0 no matter how you tweak the "*DIGIT" parts. I think that allowing a latency of ~68 years is a bit excessive. I dont think it unreasonable that we further restrict latency-param to be something like "1..31536000" (~1 year) or even a smaller range. I know none of our users are that patient. > > A) If not then we need to clearly say this in the draft and provide > > the CS some clear way to 'error out' after processing the command ("You > > have exceeded the maximum allowable time for a single command, try again > > later or simplify the command and arguments.") > > We do - send a VREPLY with an error. One problem, we have no currently defined REQUEST-STATUS code that means "Command Terminated by the CS" and then we can subclass it into "because your command took too long", "because you requested too much data", "because I dont like your hair color"... Please consider this when you consolidate the error codes in CAP... 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 0054551E85256D09_= Content-Type: text/html; charset="US-ASCII"
Hmm, not sure why this was stuck in my laptops outgoing queue.  Sorry its a bit dated (I queued it in Nov 2002) but its still relevant I think...

Doug replied on 11/18/2002 11:58:01 AM:
> > Im sorry I wasnt a bit more clear in my original posting; this change is
> > probably not sufficient.  The definition/ABNF for integer in RFC 2445 is:
> >
> >      integer    = (["+"] / "-") 1*DIGIT
> >
> >     Description: If the property permits, multiple "integer" values are
> >     specified by a COMMA character (US-ASCII decimal 44) separated list
> >     of values. The valid range for "integer" is -2147483648 to
> >     2147483647. If the sign is not specified, then the value is assumed
> >     to be positive.
> >
> > As such it is valid to have negative or "0" LATENCY.  I think CAP should
> > adopt the BEEP approach of expressly defining a range of allowed values
> > ala:
>
> And how does a positive integer like the following that I
> sent go negative?
>
>    
>       p-integer   = 1*DIGIT  ; Where DIGIT is defined in [iCAL]

You misread my posting.  I was referring to the current integer ABNF.

Your new ABNF does not allow negative numbers but it still allows for a latency of 0 no matter how you tweak the "*DIGIT" parts.  I think that allowing a latency of ~68 years is a bit excessive.  I dont think it unreasonable that we further restrict latency-param to be something like "1..31536000" (~1 year) or even a smaller range.  I know none of our users are that patient.

> >     A) If not then we need to clearly say this in the draft and provide
> > the CS some clear way to 'error out' after processing the command ("You
> > have exceeded the maximum allowable time for a single command, try again
> > later or simplify the command and arguments.")
>
> We do - send a VREPLY with an error.

One problem, we have no currently defined REQUEST-STATUS code that means "Command Terminated by the CS" and then we can subclass it into "because your command took too long", "because you requested too much data", "because I dont like your hair color"...

Please consider this when you consolidate the error codes in CAP...

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 0054551E85256D09_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 21 14:01:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24453 for ; Mon, 21 Apr 2003 14:01:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LHnkt2056613 for ; Mon, 21 Apr 2003 10:49:46 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3LHnkkR056612 for ietf-calendar-bks; Mon, 21 Apr 2003 10:49:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3LHnit2056606 for ; Mon, 21 Apr 2003 10:49:45 -0700 (PDT) (envelope-from pregen@egenconsulting.com) To: ietf-calendar@imc.org Subject: note to test list MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 21 Apr 2003 13:49:45 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/21/2003 01:49:46 PM, Serialize complete at 04/21/2003 01:49:46 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a note to validate that the mailing list is functioning ok. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Wed Apr 23 13:55:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28049 for ; Wed, 23 Apr 2003 13:55:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NHXgt2032852 for ; Wed, 23 Apr 2003 10:33:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NHXgLW032851 for ietf-calendar-bks; Wed, 23 Apr 2003 10:33:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NHXdt2032845 for ; Wed, 23 Apr 2003 10:33:40 -0700 (PDT) (envelope-from Pekka.Pessi@nokia.com) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3NHXe728886 for ; Wed, 23 Apr 2003 20:33:40 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 23 Apr 2003 20:33:40 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 23 Apr 2003 20:33:40 +0300 Received: from localhost.localdomain (hed041-219.research.nokia.com [172.21.41.219]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA20451 for ; Wed, 23 Apr 2003 20:33:39 +0300 (EETDST) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h3NHXdqb027413 for ; Wed, 23 Apr 2003 20:33:39 +0300 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id h3NHXcEa027412; Wed, 23 Apr 2003 20:33:38 +0300 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: ietf-calendar@imc.org Subject: iSIP applicability note X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) Date: Wed, 23 Apr 2003 20:33:38 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 23 Apr 2003 17:33:40.0219 (UTC) FILETIME=[7A9F1CB0:01C309BE] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello all, I have drafted the following applicability statement for iSIP. The text tries to sums up the intended applications for iSIP, and the limitations of SIP instant message service. Does anyone have other concerns about the statement? Pekka 1.1 Applicability of iSIP This subsection describes how iSIP may be useful within Internet. iSIP is used by systems whose main purpose is to set up communication sessions using Session Initiation Protocol (SIP). iSIP can be used to exchange calendaring information between such systems, when the main purpose of that exchange is to agree on suitable time, virtual venue and participants for a future SIP-based communication session. iSIP can be used to publish calendaring information when the main purpose is to announce availability of a person or a device for communication, or to announce participant roles or resources available within a communication session. iSIP does not replace iMAP or CAP as a protocol for exchanging generic calendaring information. Entities using iSIP may use iMAP or CAP when the instant delivery of a SIP message is not possible, e.g., because a recipient is out of network coverage at the moment. From owner-ietf-calendar@mail.imc.org Wed Apr 23 14:07:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28429 for ; Wed, 23 Apr 2003 14:07:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NHrct2033451 for ; Wed, 23 Apr 2003 10:53:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NHrceL033450 for ietf-calendar-bks; Wed, 23 Apr 2003 10:53:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NHrat2033436 for ; Wed, 23 Apr 2003 10:53:37 -0700 (PDT) (envelope-from seamusjg@attbi.com) Received: from garvey (12-233-1-188.client.attbi.com[12.233.1.188]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003042317533200100e3rc4e>; Wed, 23 Apr 2003 17:53:32 +0000 Reply-To: From: "Seamus Garvey" To: "'Pekka Pessi'" , Subject: RE: iSIP applicability note Date: Wed, 23 Apr 2003 10:53:49 -0700 Message-ID: <000401c309c1$4bc2c6a0$bc01e90c@attbi.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C30986.9F63EEA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_01C30986.9F63EEA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit I think this could be an incredibly useful tool, especially if integrated into IM applications or WAP enabled devices that already store schedule info. Seamus J. Garvey (925) 368-4700 (mobile) (703) 991-2654 (fax) ------=_NextPart_000_0005_01C30986.9F63EEA0 Content-Type: message/rfc822 Content-Disposition: attachment From: "Pekka Pessi" Sender: To: Subject: iSIP applicability note Date: Wed, 23 Apr 2003 10:33:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C30986.9F49FE00" X-Mailer: Microsoft Outlook, Build 10.0.2627 X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i X-OriginalArrivalTime: 23 Apr 2003 17:33:40.0219 (UTC) FILETIME=[7A9F1CB0:01C309BE] List-Unsubscribe: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C30986.9F49FE00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hello all, I have drafted the following applicability statement for iSIP. The text tries to sums up the intended applications for iSIP, and the limitations of SIP instant message service. Does anyone have other concerns about the statement? Pekka 1.1 Applicability of iSIP This subsection describes how iSIP may be useful within Internet. iSIP is used by systems whose main purpose is to set up communication sessions using Session Initiation Protocol (SIP). iSIP can be used to exchange calendaring information between such systems, when the main purpose of that exchange is to agree on suitable time, virtual venue and participants for a future SIP-based communication session. iSIP can be used to publish calendaring information when the main purpose is to announce availability of a person or a device for communication, or to announce participant roles or resources available within a communication session. iSIP does not replace iMAP or CAP as a protocol for exchanging generic calendaring information. Entities using iSIP may use iMAP or CAP when the instant delivery of a SIP message is not possible, e.g., because a recipient is out of network coverage at the moment. ------=_NextPart_000_0000_01C30986.9F49FE00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable iSIP applicability note

        Hello = all,

        I have = drafted the following applicability statement for iSIP.
        The text = tries to sums up the intended applications for iSIP,
        and the = limitations of SIP instant message service.

        Does anyone = have other concerns about the statement?

        =         =         =         =         Pekka
       =20
       =20

1.1 Applicability of iSIP

   This subsection describes how iSIP may be = useful within Internet.

   iSIP is used by systems whose main = purpose is to set up communication
   sessions using Session Initiation = Protocol (SIP). iSIP can be used to
   exchange calendaring information between = such systems, when the main
   purpose of that exchange is to agree on = suitable time, virtual venue
   and participants for a future SIP-based = communication session. iSIP
   can be used to publish calendaring = information when the main purpose
   is to announce availability of a person = or a device for
   communication, or to announce = participant roles or resources
   available within a communication = session.

   iSIP does not replace iMAP or CAP as a = protocol for exchanging
   generic calendaring information. = Entities using iSIP may use iMAP or
   CAP when the instant delivery of a SIP = message is not possible, e.g.,
   because a recipient is out of network = coverage at the moment.

------=_NextPart_000_0000_01C30986.9F49FE00-- ------=_NextPart_000_0005_01C30986.9F63EEA0-- From owner-ietf-calendar@mail.imc.org Wed Apr 23 14:24:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29155 for ; Wed, 23 Apr 2003 14:24:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NIDLt2034148 for ; Wed, 23 Apr 2003 11:13:21 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NIDLtr034147 for ietf-calendar-bks; Wed, 23 Apr 2003 11:13:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3NIDKt2034139 for ; Wed, 23 Apr 2003 11:13:20 -0700 (PDT) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003042314180201315 ; Wed, 23 Apr 2003 14:18:02 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Apr 2003 14:10:49 -0400 Message-ID: <3EA6D729.60004@centive.com> Date: Wed, 23 Apr 2003 14:10:49 -0400 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: Pekka Pessi CC: ietf-calendar@imc.org Subject: Re: iSIP applicability note References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2003 18:10:49.0959 (UTC) FILETIME=[ABA66F70:01C309C3] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Pessi wrote: > iSIP can be used to > exchange calendaring information between such systems, when the main > purpose of that exchange is to agree on suitable time, virtual venue > and participants for a future SIP-based communication session. > I don't really see why this is useful. I mean, if I need to schedule a phone conference, I don't use the phone; if I need to schedule a face-to-face meeting, I don't go talk to someone face-to-face. I use iMIP. It would be silly to expect my CUA to choose between iMIP and iSIP based on what I'm going to be doing in the session. Now, I suppose there are cases where SIP is the only protocol already available, and so you want to add a SIP binding for iTIP, rather than adding email to the device. That could be reasonable; and it could be that such cases correlate with cases where you're scheduling a SIP session. If so, you should say so; the statement as it stands seems dubious. -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |"How can one conceive of a one party system in a country that has| |over 200 varieties of cheese?" --Charles de Gaulle | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 24 15:10:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28660 for ; Thu, 24 Apr 2003 15:10:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OIqat2022404 for ; Thu, 24 Apr 2003 11:52:36 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OIqauF022403 for ietf-calendar-bks; Thu, 24 Apr 2003 11:52:36 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h3OIqYt2022398 for ; Thu, 24 Apr 2003 11:52:34 -0700 (PDT) (envelope-from pstephenson@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 24 Apr 2003 12:39:38 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 24 Apr 2003 12:50:48 -0600 From: "Preston Stephenson" To: "<" Subject: iTIP REPLY question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 I need a clarification on where the iTIP REPLY object is created in a reply to an iTIP REQUEST in CAP. Given CUA1 with CS1 and CUA2 with CS2. CUA1 creates a METHOD:REQUEST object for CUA2 in CS2. CUA2 reads the METHOD:REQUEST object in CS2. CUA2 creates the METHOD:REPLY object for CUA1. In which CS is the METHOD:REPLY object created, CS1 or CS2? The iMIP logic says it gets sent back to CS1. There is no way for iMIP to get the reply back from CUA2 in any other way than for CUA2 to send the REPLY back in an email message. In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST objects in another CUA's CS. There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT information. How do I get the rights to place METHOD:REPLY objects in another CUA's CS? How do I access the other CS? If I have to create METHOD:REPLY objects in my own CS and have other people query for METHOD:REPLY objects then that breaks the functionality with iMIP. iTIP is suppose to be transport independent, so I would expect the METHOD:REPLY to back in CS1. Thanks. Preston From owner-ietf-calendar@mail.imc.org Thu Apr 24 15:22:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29539 for ; Thu, 24 Apr 2003 15:21:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJDQt2023065 for ; Thu, 24 Apr 2003 12:13:26 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OJDQ4Y023064 for ietf-calendar-bks; Thu, 24 Apr 2003 12:13:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OJDOt2023058 for ; Thu, 24 Apr 2003 12:13:25 -0700 (PDT) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003042415181808667 for ; Thu, 24 Apr 2003 15:18:18 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Apr 2003 15:11:04 -0400 Message-ID: <3EA836C8.4010800@centive.com> Date: Thu, 24 Apr 2003 15:11:04 -0400 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: calsch Subject: Re: iTIP REPLY question References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2003 19:11:04.0916 (UTC) FILETIME=[40BED940:01C30A95] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Preston Stephenson wrote: >Given CUA1 with CS1 and CUA2 with CS2. > >CUA1 creates a METHOD:REQUEST object for CUA2 in CS2. >CUA2 reads the METHOD:REQUEST object in CS2. >CUA2 creates the METHOD:REPLY object for CUA1. > >In which CS is the METHOD:REPLY object created, CS1 or CS2? > And the other question is, why would anyone bother? Why is doing store-and-forward iTIP over CAP better than doing it over email? Why do we expect it to be compelling enough to get people to put yet another address on their business cards? -- /=============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=============================================================| |Seen in computer peripheral ad: "User-friendly dip switches!"| \=============================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 24 15:43:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00150 for ; Thu, 24 Apr 2003 15:43:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJWjt2023542 for ; Thu, 24 Apr 2003 12:32:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OJWjh0023541 for ietf-calendar-bks; Thu, 24 Apr 2003 12:32:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJWht2023536 for ; Thu, 24 Apr 2003 12:32:44 -0700 (PDT) (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 h3OJWfrl011871 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 24 Apr 2003 12:32:44 -0700 Message-ID: <3EA83BD0.5090805@Royer.com> Date: Thu, 24 Apr 2003 13:32:32 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030607050103090904000207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030607050103090904000207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Preston Stephenson wrote: > I need a clarification on where the iTIP REPLY object is created in a > reply to an iTIP REQUEST in CAP. > > Given CUA1 with CS1 and CUA2 with CS2. > > CUA1 creates a METHOD:REQUEST object for CUA2 in CS2. > CUA2 reads the METHOD:REQUEST object in CS2. > CUA2 creates the METHOD:REPLY object for CUA1. > > In which CS is the METHOD:REPLY object created, CS1 or CS2? Nether, it is created in CUA2. > The iMIP logic says it gets sent back to CS1. There is no way for iMIP > to get the reply back from CUA2 in any other way than for CUA2 to send > the REPLY back in an email message. If the ORGANIZER property in the REQUEST is a CAP uri, then CUA2 deposits the REPLY into CS1. If the ORGANIZER property is a mailto uri, then CUA2 e-mail's the REPLY to that e-mail address. > In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST > objects in another CUA's CS. > There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT > information. > > How do I get the rights to place METHOD:REPLY objects in another CUA's > CS? They must give it to you in advance. If they have not given you the rights to deposit a REPLY into their CS, then they broke iTIP - ignore them and throw away the REQUEST. It is possible that they want you to connect anonymously. > How do I access the other CS? If the ORGANIZER property is a CAP uri, then open a connection to that uri. > If I have to create METHOD:REPLY objects in my own CS and have other > people query for METHOD:REPLY objects then that breaks the functionality > with iMIP. iTIP is suppose to be transport independent, so I would > expect the METHOD:REPLY to back in CS1. No query needed from CUA1 into CS2. It is a push model. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030607050103090904000207 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MjQxOTMyMzJaMCMGCSqGSIb3DQEJBDEWBBR+ v3VhVeVgtOSa0LfUyEQ09qp0jzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEArVgKe20J8nN6 /iLl75yVYNBExKkX/J4G5hgx6sYTI+SZa6yJU4+YJiF9zds4KmGENq8NmsrT/BSNQHrJarwI Vw51I3/8ta0A9ENHI3cY0g/qM7eqoty8yvMia7IQI+SQSJvXo5VSJGtLpr0fQty173PCM+QU BMm5/KN897bORU2w9onilAo6+WfxzlO/430QIa3gIa8VSuA5L4OqM/9vy8nliA4CNwXwdElq Yd/U6aLSck48/RPWYc+HR3NpaoviGCyo7xNm0+51ukYlj+BzsDl+K566rS5r2BeghU4hJaCT v24tqGGj2jL6tvcaM2IvOegkmr1Ds/V8qyxjgaF2ggAAAAAAAA== --------------ms030607050103090904000207-- From owner-ietf-calendar@mail.imc.org Thu Apr 24 15:59:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00733 for ; Thu, 24 Apr 2003 15:59:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJpat2024576 for ; Thu, 24 Apr 2003 12:51:37 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OJpYBl024569 for ietf-calendar-bks; Thu, 24 Apr 2003 12:51:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJpUt2024517 for ; Thu, 24 Apr 2003 12:51:31 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 37C5A3F85C for ; Thu, 24 Apr 2003 21:42:59 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id 88824311; Thu, 24 Apr 2003 21:51:24 +0200 (MET DST) To: "ietf-calendar@imc.org" From: gustav.mango@safecareab.com Subject: Re: Re: iTIP REPLY question Message-Id: <20030424195124.88824311@nw-pop4.wineasy.se> Date: Thu, 24 Apr 2003 21:51:24 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Thu Apr 24 16:06:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01404 for ; Thu, 24 Apr 2003 16:06:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OJx9t2025029 for ; Thu, 24 Apr 2003 12:59:09 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OJx9G1025028 for ietf-calendar-bks; Thu, 24 Apr 2003 12:59:09 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h3OJx7t2025009 for ; Thu, 24 Apr 2003 12:59:07 -0700 (PDT) (envelope-from PStephenson@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 24 Apr 2003 13:46:10 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 24 Apr 2003 13:57:18 -0600 From: "Preston Stephenson" To: Subject: Re: iTIP REPLY question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Thanks for your response. I just want to make sure I understand. CUA1 (Organizer) creates the METHOD:REQUEST in the CS (calendar store) for CUA2 (Attendee). CUA2 processes the request and puts the reply in the CS of CUA1. He can put it there directly if the URI is CAP or he can send the reply with iMIP if the URI is a MAILTO address. This model would also work for the VFREEBUSY REQUEST. The reply VFREEBUSY REPLY is placed back in the Organizer's CS. Thanks. Preston >>> Doug@royer.com 4/24/2003 1:32:32 PM >>> Preston Stephenson wrote: > I need a clarification on where the iTIP REPLY object is created in a > reply to an iTIP REQUEST in CAP. > > Given CUA1 with CS1 and CUA2 with CS2. > > CUA1 creates a METHOD:REQUEST object for CUA2 in CS2. > CUA2 reads the METHOD:REQUEST object in CS2. > CUA2 creates the METHOD:REPLY object for CUA1. > > In which CS is the METHOD:REPLY object created, CS1 or CS2? Nether, it is created in CUA2. > The iMIP logic says it gets sent back to CS1. There is no way for iMIP > to get the reply back from CUA2 in any other way than for CUA2 to send > the REPLY back in an email message. If the ORGANIZER property in the REQUEST is a CAP uri, then CUA2 deposits the REPLY into CS1. If the ORGANIZER property is a mailto uri, then CUA2 e-mail's the REPLY to that e-mail address. > In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST > objects in another CUA's CS. > There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT > information. > > How do I get the rights to place METHOD:REPLY objects in another CUA's > CS? They must give it to you in advance. If they have not given you the rights to deposit a REPLY into their CS, then they broke iTIP - ignore them and throw away the REQUEST. It is possible that they want you to connect anonymously. > How do I access the other CS? If the ORGANIZER property is a CAP uri, then open a connection to that uri. > If I have to create METHOD:REPLY objects in my own CS and have other > people query for METHOD:REPLY objects then that breaks the functionality > with iMIP. iTIP is suppose to be transport independent, so I would > expect the METHOD:REPLY to back in CS1. No query needed from CUA1 into CS2. It is a push model. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET 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 Thu Apr 24 16:08:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01498 for ; Thu, 24 Apr 2003 16:08:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OK2At2025144 for ; Thu, 24 Apr 2003 13:02:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OK2AcG025143 for ietf-calendar-bks; Thu, 24 Apr 2003 13:02:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OK29t2025129; Thu, 24 Apr 2003 13:02:09 -0700 (PDT) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003042416070326807 ; Thu, 24 Apr 2003 16:07:03 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Apr 2003 15:59:50 -0400 Message-ID: <3EA84236.4080805@centive.com> Date: Thu, 24 Apr 2003 15:59:50 -0400 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: gustav.mango@safecareab.com CC: "ietf-calendar@imc.org" , postmaster@imc.org, postmaster@safecareab.com Subject: Re: iTIP REPLY question References: <20030424195124.88824311@nw-pop4.wineasy.se> In-Reply-To: <20030424195124.88824311@nw-pop4.wineasy.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Apr 2003 19:59:50.0541 (UTC) FILETIME=[108DCBD0:01C30A9C] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit gustav.mango@safecareab.com wrote: >Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. > > postmaster@imc.org, could you please drop gustav.mango@safecareab.com from the calsch list? He keeps sending autoreplies to list posts; he doesn't guard against duplicates (I got two); and now he's sent one to the list, which means that we're about to get a loop as soon as he gets his autoreply back from the list. CC:ing gustav.mango@safecareab.com and postmaster@safecareab.com so they know why I've asked this; CC:ing the list so people know what's going on. -- /================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================| |World domination should never be left to chance.| \================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 24 16:14:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01656 for ; Thu, 24 Apr 2003 16:14:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OK5pt2025247 for ; Thu, 24 Apr 2003 13:05:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OK5p6m025246 for ietf-calendar-bks; Thu, 24 Apr 2003 13:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OK5ot2025241 for ; Thu, 24 Apr 2003 13:05:50 -0700 (PDT) (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 h3OK5mrl012119 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 24 Apr 2003 13:05:51 -0700 Message-ID: <3EA84393.60307@Royer.com> Date: Thu, 24 Apr 2003 14:05:39 -0600 From: Doug Royer Reply-To: calsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: <3EA836C8.4010800@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000204000603010702060109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000204000603010702060109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Preston Stephenson wrote: > >> Given CUA1 with CS1 and CUA2 with CS2. >> >> CUA1 creates a METHOD:REQUEST object for CUA2 in CS2. >> CUA2 reads the METHOD:REQUEST object in CS2. >> CUA2 creates the METHOD:REPLY object for CUA1. >> >> In which CS is the METHOD:REPLY object created, CS1 or CS2? >> > And the other question is, why would anyone bother? Why is doing > store-and-forward iTIP over CAP better than doing it over email? Remember iRIP? - that's why == real time. Really needed for multi calendar synchronization. I agree it seems a waist of time for only interpersonal calendaring. > Why do > we expect it to be compelling enough to get people to put yet another > address on their business cards? Not needed, see the calendar locate RFC. Is all you need is their e-mail address or the ORGANIZER property value. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000204000603010702060109 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MjQyMDA1MzlaMCMGCSqGSIb3DQEJBDEWBBQE ZkU/4KlQsef7mzgC4paCfbqfTjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAdJC6SGsq8t9D kYLUCb6aASNB+LBADX4qIsZKZvOCZ+6BDs0OlOCmgMvXz0DiM+jdGtv9PelJycNFooDS0vHN dgf/QAujPEdyi4rRdEaP6tSoNtE4CazXLRynDuPLY8RbBhaILEBLqamamQ8Vv9XODCIgEbXp Qu/vtA6x+WRXqgem9aJ2F02A/B1tHMg5xjNP1VpuRnpDEmQTJsYryuRP3x4G8Q/SC9O7uyaQ obtLlZANz2MfeU/cs9tJ3PBWxtjrQX7V2ZiakQW541AERqO9dR8w6nJ6VEi5aK6wNDruYJyO kl7goIyu1fwItUhMZ6ZmJe/CaRd6FeESxNxzo8UQMQAAAAAAAA== --------------ms000204000603010702060109-- From owner-ietf-calendar@mail.imc.org Thu Apr 24 16:31:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02128 for ; Thu, 24 Apr 2003 16:31:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OKNGt2025812 for ; Thu, 24 Apr 2003 13:23:16 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OKNGVa025811 for ietf-calendar-bks; Thu, 24 Apr 2003 13:23:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OKNFt2025799 for ; Thu, 24 Apr 2003 13:23:15 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id 44BA73FAF6 for ; Thu, 24 Apr 2003 22:14:46 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id D30C7312; Thu, 24 Apr 2003 22:23:11 +0200 (MET DST) To: calsch From: gustav.mango@safecareab.com Subject: Re: Re: iTIP REPLY question Message-Id: <20030424202311.D30C7312@nw-pop4.wineasy.se> Date: Thu, 24 Apr 2003 22:23:11 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com. From owner-ietf-calendar@mail.imc.org Thu Apr 24 17:29:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04650 for ; Thu, 24 Apr 2003 17:29:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLJXt2028626 for ; Thu, 24 Apr 2003 14:19:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLJXLH028625 for ietf-calendar-bks; Thu, 24 Apr 2003 14:19:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OLJWt2028619 for ; Thu, 24 Apr 2003 14:19:32 -0700 (PDT) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003042417242627768 for ; Thu, 24 Apr 2003 17:24:26 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Apr 2003 17:17:13 -0400 Message-ID: <3EA85459.6000001@centive.com> Date: Thu, 24 Apr 2003 17:17:13 -0400 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: calsch Subject: Re: iTIP REPLY question References: <3EA836C8.4010800@centive.com> <3EA84393.60307@Royer.com> In-Reply-To: <3EA84393.60307@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2003 21:17:13.0705 (UTC) FILETIME=[E0186590:01C30AA6] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > John Stracke wrote: > >> And the other question is, why would anyone bother? Why is doing >> store-and-forward iTIP over CAP better than doing it over email? > > Remember iRIP? - that's why == real time. Really needed for > multi calendar synchronization. I agree it seems a waist of > time for only interpersonal calendaring. Um...OK, how do you do sync with iTIP? Or are you talking about doing a freebusy request? Because that's the only kind of iTIP request that CAP can make real-time; everything else has to wait for the CUA. (You could have a bot acting as a CUA, but you could put a bot on your mailbox, too.) >> Why do we expect it to be compelling enough to get people to put yet >> another address on their business cards? > > Not needed, see the calendar locate RFC. Is all you need is their > e-mail address or the ORGANIZER property value. Um...OK, right. -- /================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================| |World domination should never be left to chance.| \================================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 24 17:40:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05124 for ; Thu, 24 Apr 2003 17:40:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLUpt2029188 for ; Thu, 24 Apr 2003 14:30:51 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLUpLr029187 for ietf-calendar-bks; Thu, 24 Apr 2003 14:30:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3OLUot2029181 for ; Thu, 24 Apr 2003 14:30:50 -0700 (PDT) (envelope-from JStracke@centive.com) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003042417354524146 for ; Thu, 24 Apr 2003 17:35:45 -0400 Received: from centive.com ([10.10.48.156]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Apr 2003 17:28:32 -0400 Message-ID: <3EA856FF.8090601@centive.com> Date: Thu, 24 Apr 2003 17:28:31 -0400 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: calsch Subject: Re: iTIP REPLY question References: <3EA836C8.4010800@centive.com> <3EA84393.60307@Royer.com> <3EA85459.6000001@centive.com> In-Reply-To: <3EA85459.6000001@centive.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2003 21:28:32.0102 (UTC) FILETIME=[74739060:01C30AA8] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>> Why do we expect it to be compelling enough to get people to put yet >>> another address on their business cards? >> >> Not needed, see the calendar locate RFC. Is all you need is their >> e-mail address or the ORGANIZER property value. > > Um...OK, right. No, wait a minute--are you talking about RFC-2739, "Calendar Attributes for vCard and LDAP"? That doesn't solve anything unless you have someone's vCard (rare) or access to their LDAP server (even rarer, unless you're in the same organization). You can still initiate a conversation with someone with just their email address; but, if nobody knows anybody else's cap: address, when is iTIP-over-CAP going to get used? But, for a more fundamental question: Why do we expect it to be compelling enough to be worth implementing support for iTIP-over-CAP as well as iMIP? If users don't get much extra functionality, and if they don't want the hassle of keeping track of people's cap: addresses, why should we ask implementers to bother? -- /==========================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==========================================| |Belief is not relevant to truth. | \==========================================/ From owner-ietf-calendar@mail.imc.org Thu Apr 24 18:03:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05951 for ; Thu, 24 Apr 2003 18:03:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLlgt2029956 for ; Thu, 24 Apr 2003 14:47:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLlflM029955 for ietf-calendar-bks; Thu, 24 Apr 2003 14:47:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLlet2029950 for ; Thu, 24 Apr 2003 14:47:40 -0700 (PDT) (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 h3OLlcrl012883 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 24 Apr 2003 14:47:41 -0700 Message-ID: <3EA85B71.9040204@Royer.com> Date: Thu, 24 Apr 2003 15:47:29 -0600 From: Doug Royer Reply-To: calsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question (realtime) References: <3EA836C8.4010800@centive.com> <3EA84393.60307@Royer.com> <3EA85459.6000001@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080406010705030107050006" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080406010705030107050006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> John Stracke wrote: >> >>> And the other question is, why would anyone bother? Why is doing >>> store-and-forward iTIP over CAP better than doing it over email? >> >> >> Remember iRIP? - that's why == real time. Really needed for >> multi calendar synchronization. I agree it seems a waist of >> time for only interpersonal calendaring. > > > Um...OK, how do you do sync with iTIP? Without a real time connection, how will you ever be able to do real time synchronization? And we deferred that topic. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080406010705030107050006 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MjQyMTQ3MjlaMCMGCSqGSIb3DQEJBDEWBBQ7 IgBAWNwzklXmXWljmDL8Js1hAjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAp1bSFO1RFlsh 66mbigyDmsyUiAk5hCqdxSHW1t3Qjm5QU//bqw/cwFLasC6A2cujxvpZgOEL3ctkJYyG1AG/ QMCq2zvyzLMxIzPcSiUyC4mt93XfuhNgRgg+wLFdsNf942w68T4+n/rqng/YrVV4H7dD5G0X dcPt//d9xKCZaNoO6JQP/Z3dXqQl7X1gL3tgln3mbHPUa0zrBhWZybrFX5g28mn0kMndoNDQ ntlRGs+m7YUokzI+dmHDXC/lE2BN6AJ0QfdwD7bSrc6Fg0HWncoDnxee6+Umhf8rAip8STQo q8IM8311+83SU6K3gDqOINlgfNibGdd8fgSD7HwURAAAAAAAAA== --------------ms080406010705030107050006-- From owner-ietf-calendar@mail.imc.org Thu Apr 24 18:06:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06740 for ; Thu, 24 Apr 2003 18:06:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLuEt2030291 for ; Thu, 24 Apr 2003 14:56:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLuENK030290 for ietf-calendar-bks; Thu, 24 Apr 2003 14:56:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLuCt2030285 for ; Thu, 24 Apr 2003 14:56:13 -0700 (PDT) (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 h3OLuArl012947 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 24 Apr 2003 14:56:14 -0700 Message-ID: <3EA85D75.1060700@Royer.com> Date: Thu, 24 Apr 2003 15:56:05 -0600 From: Doug Royer Reply-To: calsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question (realtime) References: <3EA836C8.4010800@centive.com> <3EA84393.60307@Royer.com> <3EA85459.6000001@centive.com> <3EA856FF.8090601@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010204000007010902030600" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010204000007010902030600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > But, for a more fundamental question: Why do we expect it to be > compelling enough to be worth implementing support for iTIP-over-CAP as > well as iMIP? If users don't get much extra functionality, and if they > don't want the hassle of keeping track of people's cap: addresses, why > should we ask implementers to bother? (1) Real time calendaring. -to be defined but will require a live connection. (2) Not subject to e-mail delays across possible hundreds of calendars. And you VFREEBUSY example is a good example. (3) Not bothered by some vendors limited processing of iCalendar objects sent via e-mail. Your CUA can work even if vendor-M fails to correctly process iCalendar objects. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010204000007010902030600 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MjQyMTU2MDVaMCMGCSqGSIb3DQEJBDEWBBT4 Pc5aIa0sEAoJjUaa92ADv9PgojBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAAXjA82IohDW8 tdujR43V0g6WZX0qpmW0MuDziE6G3BhrR9xZGFeBHulPm1kj05rMaJnPrb5kmRUIUNHIoG8l HeFbNn/DAAWPkNgq6m6Z7bMNqI0NV5pNAe0W+SgfnJRkZJpc/s1Fetq69Fn+y0PcoshRro2A PqMbQquezsbSpoBMqstFRKPzGOij9yMJDrBxlzRgyhpg1mlCdXK/JO0JdOMgqSckEDddURXR av92vdKEobie3yF8iHICL6fbK0PQKkXXmSswavWL+uUzHRAlH30a78e8xrE4fs4P2K+AYIGB YoSe62d25aAVtQqOU9dbSUsDK0uh5Gdj6xl6DybEYAAAAAAAAA== --------------ms010204000007010902030600-- From owner-ietf-calendar@mail.imc.org Thu Apr 24 18:10:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07125 for ; Thu, 24 Apr 2003 18:10:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLvUt2030341 for ; Thu, 24 Apr 2003 14:57:30 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OLvUol030340 for ietf-calendar-bks; Thu, 24 Apr 2003 14:57:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OLvTt2030334 for ; Thu, 24 Apr 2003 14:57:29 -0700 (PDT) (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 h3OLvSrl012953 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 24 Apr 2003 14:57:30 -0700 Message-ID: <3EA85DC2.3020603@Royer.com> Date: Thu, 24 Apr 2003 15:57:22 -0600 From: Doug Royer Reply-To: calsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: <3EA836C8.4010800@centive.com> <3EA84393.60307@Royer.com> <3EA85459.6000001@centive.com> <3EA856FF.8090601@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090501070608070806000509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090501070608070806000509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: >>> >>> Not needed, see the calendar locate RFC. Is all you need is their >>> e-mail address or the ORGANIZER property value. >> >> >> Um...OK, right. > > > No, wait a minute--are you talking about RFC-2739, "Calendar Attributes > for vCard and LDAP"? That doesn't solve anything unless you have > someone's vCard (rare) or access to their LDAP server (even rarer, > unless you're in the same organization). Did you have another proposal? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090501070608070806000509 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MjQyMTU3MjJaMCMGCSqGSIb3DQEJBDEWBBRC IjPVr2LP8xYhQ5b2UrJ+RSV2ZDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAY/A3J7whOIs6 wA9S5Z/hX0kRYInAmU9LSWe0hA4GAPIRqwJJjaB03kDyvAdnO75nMIpn9mRRrhKYLtxuQX74 XFYv6zYpcveckk5aVzEiJgZcXUJMpK4p57YyWG0cqdwBaDitF5yniMW5moa1rhHmowMtAb0Y bhQYXTr9xa0hj7+Z5EzVW/0uU9zMtsSmxnoUQcc/Tv+bPRhLCC6dM87hwG5BWzfHiiRpiFbf 4OUV9UMtluwaoW+OtucLW9dTTGbj3d7lcMhYiNN+bcexNhGLKC9iBufsH5zdVUmzo6WNIVzg 66plcF8xWONxigChFnZzDowgV2LZ/+Y8NgRK3JX/lQAAAAAAAA== --------------ms090501070608070806000509-- From owner-ietf-calendar@mail.imc.org Fri Apr 25 01:47:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16426 for ; Fri, 25 Apr 2003 01:47:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3P5att2046934 for ; Thu, 24 Apr 2003 22:36:55 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3P5asIk046933 for ietf-calendar-bks; Thu, 24 Apr 2003 22:36:55 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h3P5art2046928 for ; Thu, 24 Apr 2003 22:36:53 -0700 (PDT) (envelope-from jparker@gw.novell.com) Received: from PROVO3-MTA by gw.provo.novell.com with Novell_GroupWise; Thu, 24 Apr 2003 23:24:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 24 Apr 2003 23:31:23 -0600 From: "Jay Parker" To: Subject: Re: iTIP REPLY question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Could someone please provide clarification in the following areas: 1. Can both an email address and a CAP uri be specified for the organizer so that if rights haven't been granted for opening a connection then the CUA can fall back to the email address? If so how is it done? If not, and both a CAP uri and an email address are available - which should be preferred when creating an iTIP request? 2. It's not clear to me which pre-defined rights are checked when depositing an iTIP reply object. I.E. Is CARID:UPDATEPARTSTATUS VCAR checked? Does this right cover both VEVENT and VFREEBUSY components? Or does each store need to implement additional VCARs such as a hypothetical CARID:UPDATEBUSYTIMEINFO. Do I need to create a VCAR to handle the email address AND a VCAR to handle the CAP uri? 3. A CUA that is ready to process an iTIP reply that was delivered via iMIP is expected to check the VCARs in the same manner as if it was transported via CAP, correct? >>> Doug@royer.com 4/24/2003 1:32:32 PM >>> Preston Stephenson wrote: > I need a clarification on where the iTIP REPLY object is created in a > reply to an iTIP REQUEST in CAP. > > Given CUA1 with CS1 and CUA2 with CS2. > > CUA1 creates a METHOD:REQUEST object for CUA2 in CS2. > CUA2 reads the METHOD:REQUEST object in CS2. > CUA2 creates the METHOD:REPLY object for CUA1. > > In which CS is the METHOD:REPLY object created, CS1 or CS2? Nether, it is created in CUA2. > The iMIP logic says it gets sent back to CS1. There is no way for iMIP > to get the reply back from CUA2 in any other way than for CUA2 to send > the REPLY back in an email message. If the ORGANIZER property in the REQUEST is a CAP uri, then CUA2 deposits the REPLY into CS1. If the ORGANIZER property is a mailto uri, then CUA2 e-mail's the REPLY to that e-mail address. > In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST > objects in another CUA's CS. > There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT > information. > > How do I get the rights to place METHOD:REPLY objects in another CUA's > CS? They must give it to you in advance. If they have not given you the rights to deposit a REPLY into their CS, then they broke iTIP - ignore them and throw away the REQUEST. It is possible that they want you to connect anonymously. > How do I access the other CS? If the ORGANIZER property is a CAP uri, then open a connection to that uri. > If I have to create METHOD:REPLY objects in my own CS and have other > people query for METHOD:REPLY objects then that breaks the functionality > with iMIP. iTIP is suppose to be transport independent, so I would > expect the METHOD:REPLY to back in CS1. No query needed from CUA1 into CS2. It is a push model. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET 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 Apr 25 13:13:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15373 for ; Fri, 25 Apr 2003 13:13:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PH08t2016573 for ; Fri, 25 Apr 2003 10:00:08 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PH08ke016572 for ietf-calendar-bks; Fri, 25 Apr 2003 10:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PH06t2016564 for ; Fri, 25 Apr 2003 10:00:06 -0700 (PDT) (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 h3PH03rl021223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 25 Apr 2003 10:00:06 -0700 Message-ID: <3EA96989.4010606@Royer.com> Date: Fri, 25 Apr 2003 10:59:53 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP REPLY question References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090203060005080005020702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090203060005080005020702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jay Parker wrote: > Could someone please provide clarification in the following areas: > > 1. Can both an email address and a CAP uri be specified for the > organizer so that if rights haven't been granted for opening a > connection then the CUA can fall back to the email address? If so how > is it done? If not, and both a CAP uri and an email address are > available - which should be preferred when creating an iTIP request? RFC 2445 limits one URI value to ORGANIZER RFC 2446 limits one ORGANIZER to a VEVENT. So currently no, you can not have both for the same ORGANIZER. As to which is preferred: If you can let then REPLY via CAP, you cap if you wish. If not, e-mail them and give them an e-mail reply. > 2. It's not clear to me which pre-defined rights are checked when > depositing an iTIP reply object. Nothing is specified. So, (1) try it or (2) query for the VCARs and figure it out. I would think that (1) would be faster and require less round trips. > I.E. Is CARID:UPDATEPARTSTATUS VCAR checked? I an not sure what you mean by 'checked'. It applies (per CAP) to booked components, not unscheduled entries. > Does this right cover both VEVENT and VFREEBUSY components? The text in CAP says "... in any components ..." if this question applies to UPDATEPARTSTATUS. > Or does each store need to implement additional VCARs such as a > hypothetical CARID:UPDATEBUSYTIMEINFO. Do I need to create a VCAR to > handle the email address AND a VCAR to handle the CAP uri? VCARs apply to UPNs, not CAP or e-mail URI's. In cap-10: Calendar Access Rights (VCAR) - The mechanism for specifying the CAP operations ("PERMISSION") that a particular calendar user ("UPN") is granted or denied permission to perform on a given calendar object ("SCOPE"). The calendar access rights are specified with a "VCAR" component. (Section 9.3. > 3. A CUA that is ready to process an iTIP reply that was delivered via > iMIP is expected to check the VCARs in the same manner as if it was > transported via CAP, correct? A 'CS' would check the VCARs if the 'CUA' attempts any operation. However the CUA is free to query for the VCARs and decide before the operation. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090203060005080005020702 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MjUxNjU5NTNaMCMGCSqGSIb3DQEJBDEWBBTh Ct6lt9AySdlBKAu0xTovSuF1ATBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEADI4kjt5AeOU5 xbJ5B2C9fpciaie5tvikPF+2RiZynHlE1dywiKPfuB3J0ZzBqhGb0bycKBJEGixXNnxTSbcP +4qTyVSsfGjL7auvdFWHw7NhEAd4uU0L8tS7ewfHbSErZDsmrm7PaRpvXCWjV3ps2/NdBHTo /EmlED6TggZIfzIJ7s/n8+W60Vpf6U6uRXUVcEQw/qQwF/PBVuJo1f6ypNu4UNYAyE1Bbi0L 22fx+uS2JZHsc5ZfQQrD6SN+rPIl8mu6DHivWvOMMFsP1lKn0QQwJCpCiU/JLCYWmnLbmJQl BLjX0RSWzQi6iLYSUCCyemwbOYAmp80jDlSWKelepwAAAAAAAA== --------------ms090203060005080005020702-- From owner-ietf-calendar@mail.imc.org Fri Apr 25 13:30:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16027 for ; Fri, 25 Apr 2003 13:30:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PHMAt2018446 for ; Fri, 25 Apr 2003 10:22:10 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3PHMARu018444 for ietf-calendar-bks; Fri, 25 Apr 2003 10:22:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from nw-smtp.wineasy.se (nw-smtp-02.wineasy.se [195.42.210.227]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3PHM9t2018438 for ; Fri, 25 Apr 2003 10:22:09 -0700 (PDT) (envelope-from gustav.mango@safecareab.com) Received: from nw-pop4.wineasy.se (nw-pop4.wineasy.se [195.42.210.225]) by nw-smtp.wineasy.se (Postfix) with ESMTP id B8F403FB30 for ; Fri, 25 Apr 2003 19:13:37 +0200 (CEST) Received: by nw-pop4.wineasy.se (Postfix, from userid 201) id 5F9EB311; Fri, 25 Apr 2003 19:22:05 +0200 (MET DST) To: ietf-calendar@imc.org From: gustav.mango@safecareab.com Subject: Re: Re: iTIP REPLY question Message-Id: <20030425172205.5F9EB311@nw-pop4.wineasy.se> Date: Fri, 25 Apr 2003 19:22:05 +0200 (MET DST) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personen ni söker har avslutat sin anställning på Safe-Care. Vill ni komma i kontakt med oss når ni oss på info@safecareab.com.