Subject: [calsify] VAVAILABILITY and priorities

From: Evert Pot <[email-masked]>
Date: Tue, 14 Jul 2015 00:13:26 -0400

Hey guys,

I'm in the process of implementing VAVAILABILITY into sabre/dav. We are
interested in the specification and it solves a real need.

So far the specification looks pretty great, but if I'm interpreting it
correctly, I do have some concerns:

### non-unique priorities

The current draft states[1]:

> If
> two or more vavailability components have the same PRIORITY value,
> then their AVAILABILITY components which fall within the date range
> of interest are combined.  It is up to the creator of such components
> to ensure that combining them produces a consistent and expected
> result.

This basically leaves it up to the implementer to decide how to
interpret the result, and could leave to inconsistencies. I don't know
for instance which BUSYTYPE to take as the default.

The difference is subtle, but could lead to frustrations in the future.
I would want to suggest one of three solutions:

1. Force uniqueness of the value of PRIORITY.
2. Take the order in which the VAVAILABILITY component appears as
   significant, and treat the ones that appear later as a slightly
   higher priority. (assuming people will generally want to append)
3. Remove PRIORITY altogether and *only* use the order of components as
   their priority.

### Order of AVAILABLE

Similar to VAVAILABILITY, multiple AVAILABLE components within a single
VAVAILABILITY can also generate conflicting, overlapping results.

The way I'm currently processing this is simply by using their specified
order, and treat the last AVAILABLE component as "most significant".

I feel that it would be good to *if* this is the intended behavior, that
this is also specified.

### Cosmetic: casing

I noticed there's a lot of variation in the document in how
VAVAILABILITY (or vavailability or Vavailability) is written.

### Question: relation to VFREEBUSY

Both VAVAILABILITY and VFREEBUSY address a similar use-case, the ability
to indicate when somebody is available or busy.

VAVAILABILITY does this much better because it can use recurrence rules,
but VAVAILABILITY is not great for marking off small parts of the day
(when there's an event for instance).

What do I do if I want to publish my availability information that:

* Is timezone and recurrence aware
* Can also block off specific timeslots

I feel that it's very useful for say, a dentist to be able to publish
office hours as well as which timeslots are already booked off. Could I
just create a single document that has both VFREEBUSY and VAVAILABILITY
components?

Cheers and well done =)

Evert

[1]:
https://tools.ietf.org/html/draft-daboo-calendar-availability-05#section-4

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 17 Jul 2015 10:06:40 -0400

Hi Evert,
Thanks for your review - comments in line. I'll work through your other 
emails too.

> 3. Remove PRIORITY altogether and *only* use the order of components as

I don't think we can rely on order as (1) iCalendar itself puts no 
requirements on ordering of components so it is quite possible that 
existing iCalendar libraries can re-order components in an arbitrary 
fashion (and they would not be wrong to do so), and (2) that does not help 
when combining availability from multiple iCalendar resources on a CalDAV 
server as again there is no well-defined ordering for resources.

So, for this case what I propose doing is adding text to clarify how 
overlapping, same-priority, VAVAILABILITY should be handled:

    When two or more VAVAILABILITY components overlap, and they have the
    same PRIORITY value, the overlapping busy time type is determined by
    the following order: BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE. i.e., if
    one component has a BUSYTYPE set to BUSY, and the another has BUSYTYPE
    set to BUSY-UNAVAILABLE, then the effective busy time type over the
    time range that they overlap would be BUSY.

> I feel that it would be good to *if* this is the intended behavior, that

Each AVAILABLE component "carves out" a block of free time from the 
"background" busy time range defined by the VAVAILABILITY component that 
encompasses the AVAILABLE component. So overlapping components result in 
the aggregate time-range being marked as free. e.g., AVAILABLE #1 starts at 
9 am ends at 12 pm, AVAILABLE #2 starts at 11 am ends at 3 pm, then the 
overall free time is 9 am to 3 pm. I think that is described by the 
following text:

    Step through the resulting list of "VAVAILABILITY" components. For
    each, the time range covered by the "VAVAILABILITY" component is set to
    busy and then portions of it defined by the "AVAILABLE" components in
    the "VAVAILABILITY" component are set to free.

If you want I can add a sentence or two to the end of that to clarify the 
overlapping behavior.

> VAVAILABILITY (or vavailability or Vavailability) is written.

Yup - I will go through and fix that.

> just create a single document that has both VFREEBUSY and VAVAILABILITY

Yes, that is fine. In fact I think that is described in Section 5 which 
shows how the overall free-time of a calendar user is calculated based on 
all the iCalendar components that apply to them. In the case of CalDAV 
those components would all be separate resources in one or more of their 
calendars, but for other situations it could be whatever is in a 
"monolithic" iCalendar file.

-- 
Cyrus Daboo

---

From: Evert Pot <[email-masked]>
Date: Fri, 17 Jul 2015 12:28:42 -0400

Hi Cyrus,

> fashion (and they would not be wrong to do so), and (2) that does not
> help when combining availability from multiple iCalendar resources on a
> CalDAV server as again there is no well-defined ordering for resources.
> 

Hm... even then there would be a chance of multiple overlapping
components, if they have the same BUSYTYPE.

Even if the answer to that is that it's 'left undefined', it would still
be worthwhile to update that paragraph to say that. I think in real-life
scenarios it might not really be important.

> the aggregate time-range being marked as free. e.g., AVAILABLE #1 starts
> at 9 am ends at 12 pm, AVAILABLE #2 starts at 11 am ends at 3 pm, then
> the overall free time is 9 am to 3 pm. I think that is described by the
> following text:
> 
> If you want I can add a sentence or two to the end of that to clarify
> the overlapping behavior.

I actually take back this comment. I'm further along implementing this
and now this makes total sense =)

> shows how the overall free-time of a calendar user is calculated based
> on all the iCalendar components that apply to them. In the case of
> CalDAV those components would all be separate resources in one or more
> of their calendars, but for other situations it could be whatever is in
> a "monolithic" iCalendar file.

Thanks, that sounds good!

Evert