Subject: iTIP Bug: VFREEBUSY REPLYs

From: [email-masked]
Date: Wed, 2 Apr 2003 10:19:27 -0500

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: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 10:52:29 -0500

[email-masked] 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      [email-masked]                     |
|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: [email-masked]
Date: Wed, 2 Apr 2003 14:52:30 -0500

> 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 

> 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.

> 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