[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
iTIP Bug: VFREEBUSY REPLYs
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@xxxxxxxxxxxxxxxx
Messaging & Collaboration
Phone: 978.399.6496
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...