Subject: To show Busy OR not to show Busy

From: suchet singh khalsa <[email-masked]>
Date: Mon, 03 Jun 2002 22:38:19 +0000

Hi All,

I have joined late in the game... So answers
needed for some fundamental questions. Any help will be greatly appreciated.

(I have formatted my questions in HTML Table. Hope it does
not get garbled...)

Sr. No.

Reference

Background for the Question

Q. No.

Question

1.

iTIP / FreeBusy

Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent
has STATUS set to CONFIRMED.

Another Calendar User Bill wants to see FreeBusy of Mary and Tom for
the period of Mary's meeting.

1.

Should Mary be shown to be BUSY as she is the ORGANIZER and she is
by default expected to attend the meeting?

(Assume that she has not set role to non-participant)

2.

Case 1: PartStat for Tom is still NEEDS-ACTION:

Should Tom be shown to be BUSY ?

3.

Case 2: PartStat for Tom is DECLINED:

Should Mary be shown BUSY now or since all attendees have declined
to attend, she should be shown FREE?

2.

iTIP / FreeBusy

Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent
has STATUS set to TENTATIVE.

Another Calendar User Bill wants to see FreeBusy of Mary and Tom for
the period of Mary's meeting.

1.

Should Mary be shown to be BUSY even though she has created the vevent
with status TENTATIVE ?

2.

If PartStat for Tom is NEEDS-ACTION should he be shown BUSY ?

3.

iTIP / REPLY, CANCEL

Restriction Table for these methods allows 0+ occurrences of the following
properties:

RRULE , RDATE, EXRULE, EXDATE,

CONTACT, ATTACH,

RELATED-TO

1.

What significance do these properties have in the MIME object
having these methods ?

Is it that the RRULE received in REPLY method should be interpreted
like this :  if attendee is ACCEPTing then he means to ACCEPT only
for those instances determined by the RRULE in the REPLY ?

2.

I cannot make sense of an ATTACH property in a MIME object with
method REPLY or CANCEL.

Similarly for the properties CONTACT and RELATED-TO.

4.

CAP / VCAR

There are 2 VCARs defined with TARGET as calendar id "CAL-PARENT".

There are 3 VCARs defined with TARGET as calendar id "CAL-CHILD".

The Calendar "CAL-CHILD" is contained in the calendar "CAL-PARENT"

The word "calendar" in the above three statements means VAGENDA as
defined by CAP.

1.

Whenever any operation is to be done on the calendar "CAL-CHILD" should
the VCARs defined on calendar "CAL-PARENT" also be considered ?

2.

For e.g.: A REQUEST is received for a vevent with TARGET as
"CAL-CHILD". This operation does not violate any VCARs defined on "CAL-CHILD" but
one of the VCARs defined on "CAL-PARENT" is violated. Should this operation
be allowed or not ?

Thanks in advance,

Suchet Singh Khalsa

Oracle Corporation

Disclaimer : The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation.

---

From: Doug Royer <[email-masked]>
Date: Mon, 03 Jun 2002 11:55:56 -0600

suchet singh khalsa wrote:
> 
> 
> Hi All,
>      I have joined late in the game... So answers needed for some
> fundamental questions. Any help will be greatly appreciated.
> 
> (I have formatted my questions in HTML Table. Hope it does not get
> garbled...)

HTML is not a good thing to send to most (all?) ietf lists.

(1-2):
Busy time is determined by the attendee, not the iTIP object.
I could have the same entries in my calendar - and not plan
to attend. So I would not mark them as busy time.
 
(3):
[I am not sure which table your are referring to here and in
which draft. iTIP? CAP?]
I think this may help:
Your can CANCEL instances of an object. So they would exist
in the object when an instance or specific instances are
being canceled / acknowledges / ...

(4): 
No and No. There is no VCAR inheritance. Each calendar
is independent. The only exception being that they can not
violate any decreed VCARs.

---

From: [email-masked] (Steve Mansour)
Date: Mon, 03 Jun 2002 11:06:27 -0700

Here's my opinion:

Sr. No. 1
1. Mary should be shown as busy
2. Tom should be shown as busy
3. Mary should be shown as busy, Tom should be shown as free

Sr. No. 2
1. Mary should be shown as busy
2. Tom should be shown as busy

Sr. No 3
1. In the case you describe, I think the REPLY would apply only to those
instances called out in the RRULE(s).
2. We believe them to be harmless. Do you see a reason that should cause
us to preclude them from the reply?

I'll respond to the CAP questions later.

-Steve

suchet singh khalsa wrote:

> Sr.             Background for Q.
  No.  Reference  the Question   No.  Question
                  Mary has
                  REQUESTed a
                  vevent with
                  Tom as
                  attendee. The       Should Mary be
                  REQUESTed           shown to be BUSY as
                  vevent has          she is the
                  STATUS set to       ORGANIZER and she
  1.   iTIP /     CONFIRMED.     1.   is by default
       FreeBusy   Another             expected to attend
                  Calendar User       the meeting?
                  Bill wants to       (Assume that she
                  see FreeBusy        has not set role to
                  of Mary and         non-participant)
                  Tom for the
                  period of
                  Mary's
                  meeting.
                                      Case 1: PartStat
                                      for Tom is still
                                 2.   NEEDS-ACTION:
                                      Should Tom be shown
                                      to be BUSY ?
                                      Case 2: PartStat
                                      for Tom is
                                      DECLINED:
                                      Should Mary be
                                 3.   shown BUSY now or
                                      since all attendees
                                      have declined to
                                      attend, she should
                                      be shown FREE?

                  Mary has
                  REQUESTed a
                  vevent with
                  Tom as
                  attendee. The
                  REQUESTed
                  vevent has          Should Mary be
                  STATUS set to       shown to be BUSY
  2.   iTIP /     TENTATIVE.     1.   even though she has
       FreeBusy   Another             created the vevent
                  Calendar User       with status
                  Bill wants to       TENTATIVE ?
                  see FreeBusy
                  of Mary and
                  Tom for the
                  period of
                  Mary's
                  meeting.
                                      If PartStat for Tom
                                 2.   is NEEDS-ACTION
                                      should he be shown
                                      BUSY ?

                                      What significance
                                      do these properties
                  Restriction         have in the MIME
                  Table for           object having these
                  these methods       methods ?
                  allows 0+
                  occurrences of      Is it that the
       iTIP /     the following       RRULE received in
  3.   REPLY,     properties:    1.   REPLY method should
       CANCEL     RRULE , RDATE,      be interpreted like
                  EXRULE,             this :  if attendee
                  EXDATE,             is ACCEPTing then
                  CONTACT,            he means to ACCEPT
                  ATTACH,             only for those
                  RELATED-TO          instances
                                      determined by the
                                      RRULE in the REPLY
                                      ?
                                      I cannot make sense
                                      of an ATTACH
                                      property in a MIME
                                 2.   object with method
                                      REPLY or CANCEL.
                                      Similarly for the
                                      properties CONTACT
                                      and RELATED-TO.

                  There are 2
                  VCARs defined
                  with TARGET as
                  calendar id
                  "CAL-PARENT".

                  There are 3
                  VCARs defined
                  with TARGET as
                  calendar id         Whenever any
                  "CAL-CHILD".        operation is to be
                                      done on the
                                      calendar
  4.   CAP /      The Calendar   1.   "CAL-CHILD" should
       VCAR       "CAL-CHILD" is
                  contained in        the VCARs defined
                  the calendar        on calendar
                  "CAL-PARENT"        "CAL-PARENT" also
                                      be considered ?
                  The word
                  "calendar" in
                  the above
                  three
                  statements
                  means VAGENDA
                  as defined by
                  CAP.
                                      For e.g.: A REQUEST
                                      is received for a
                                      vevent with TARGET
                                      as "CAL-CHILD".
                                      This operation does
                                      not violate any
                                 2.   VCARs defined on
                                      "CAL-CHILD" but one
                                      of the VCARs
                                      defined on
                                      "CAL-PARENT" is
                                      violated. Should
                                      this operation be
                                      allowed or not ?

---

From: [email-masked] (Steve Mansour)
Date: Mon, 03 Jun 2002 13:34:39 -0700

Doug Royer wrote:

> Steve Mansour wrote:
> It's up to the CU/CUA to decide if they want there time
> marked as BUSY, not the protocol. Correct?

yep. that's why I indicated that it's my opinion.

My take is that when a person has been requested to show up at a
meeting, you should show their time as busy (that is, if you only have a
choice between 'free' or 'busy'; there's no option like 'pending'). As
an example, assume that I've been invited to a meeting Monday from
10:00a to 11:00a. If other people see me as busy at that time (even
though I've not actually accepted the meeting) they can invite me to
their meeting at some other time when I'm completely free. On the other
hand, if my time on Monday from 10:00 - 11:00 was marked as free, then
other people might invite me to a meeting from 10-11. I would only be
able to accept one of the invitations, and I would decline the others.
Similar double-bookings would be sure to happen with other attendees. I
believe that the overall amount of hassle and swirl associated with
getting the meeting scheduled will greatly increase if "needs action"
time is shown as free rather than busy.

iTIP provides capability to indicate whatever is appropriate, but not
the policy.

-Steve

---

From: Patrice Lapierre <[email-masked]>
Date: 03 Jun 2002 16:44:13 -0400

My opinions:

Sr.No. 1

  Q.No. 1) No, since Mary is not an ATTENDEE. The ORGANIZER is not
           by default expected to attend the meeting.
  
  Q.No. 2) No, since Tom hasn't accepted the meeting.
  
  Q.No. 3) Yes, since she is not an attendee, and not because 
           Tom declined.

Sr.No. 2

  Q.No. 1) If Mary is not an attendee, then no.
           
  Q.No. 2) No, since Tom hasn't accepted the meeting.

  Note: Tentative intervals in you agenda should have the value
        "BUSY-TENTATIVE".
  
Sr.No. 3

  Q.No 1 and 2)

    My guess is that an almost complete component might be useful 
    to allow a simple MUA/CUA to display information about the
    subject of reply/cancellation without accessing a database.

    For question 1) the RECURRENCE-ID should be used to identify 
    a single instance of a recurring event (not RRULE).

Sr.No. 4

  VAGENDA hierarchy and VCAR inheritance were removed from CAP.
  
  Q.No. 1) No.

  Q.No. 2) Yes.

--
Patrice

On Mon, 2002-06-03 at 18:38, suchet singh khalsa wrote:   
Hi All, 
     I have joined late in the game... So answers needed for some
fundamental questions. Any help will be greatly appreciated. 

Sr. No.
Reference
Background for
the Question
Q. No.
Question
1.
iTIP /
FreeBusy
Mary has
REQUESTed a
vevent with
Tom as
attendee. The
REQUESTed
vevent has
STATUS set to
CONFIRMED. 
Another
Calendar User
Bill wants to
see FreeBusy
of Mary and
Tom for the
period of
Mary's
meeting.
1.
Should Mary be
shown to be
BUSY as she is
the ORGANIZER
and she is by
default
expected to
attend the
meeting?  
(Assume that
she has not
set role to
non-participant)

2.
Case 1:
PartStat for
Tom is still
NEEDS-ACTION: 
Should Tom be
shown to be
BUSY ?

3.
Case 2:
PartStat for
Tom is
DECLINED: 
Should Mary be
shown BUSY now
or since all
attendees have
declined to
attend, she
should be
shown FREE?

2.
iTIP /
FreeBusy
Mary has
REQUESTed a
vevent with
Tom as
attendee. The
REQUESTed
vevent has
STATUS set to
TENTATIVE. 
Another
Calendar User
Bill wants to
see FreeBusy
of Mary and
Tom for the
period of
Mary's
meeting.
1.
Should Mary be
shown to be
BUSY even
though she has
created the
vevent with
status
TENTATIVE ?

2.
If PartStat
for Tom is
NEEDS-ACTION
should he be
shown BUSY ?

3.
iTIP / REPLY,
CANCEL
Restriction
Table for
these methods
allows 0+
occurrences of
the following
properties: 
RRULE , RDATE,
EXRULE,
EXDATE, 
CONTACT,
ATTACH, 
RELATED-TO
1.
What
significance
do these
properties
have in the
MIME object
having these
methods ? 

Is it that the
RRULE received
in REPLY
method should
be interpreted
like this : 
if attendee is
ACCEPTing then
he means to
ACCEPT only
for those
instances
determined by
the RRULE in
the REPLY ?

2.
I cannot make
sense of an
ATTACH
property in a
MIME object
with method
REPLY or
CANCEL. 
Similarly for
the properties
CONTACT and
RELATED-TO.

4.
CAP / VCAR
There are 2
VCARs defined
with TARGET as
calendar id
"CAL-PARENT". 

There are 3
VCARs defined
with TARGET as
calendar id
"CAL-CHILD". 

The Calendar
"CAL-CHILD" is
contained in
the calendar
"CAL-PARENT" 

The word
"calendar" in
the above
three
statements
means
VAGENDA as
defined by
CAP.
1.
Whenever any
operation is
to be done on
the calendar
"CAL-CHILD"
should the
VCARs defined
on calendar
"CAL-PARENT"
also be
considered ?

2.
For e.g.: A
REQUEST is
received for a
vevent with
TARGET as
"CAL-CHILD".
This operation
does not
violate any
VCARs defined
on
"CAL-CHILD" but one of the VCARs defined on "CAL-PARENT" is violated.
Should this operation be allowed or not ?

Thanks in advance, 
Suchet Singh Khalsa 
Oracle Corporation