Perhaps this narrative will provide insight that some might find compelling. . .
We have a preliminary CAP implementation in use by customers (early adopters) both inside and outside our organization. Months ago, we were attempting to satisfy the need of these customers to perform a CAP real-time busy search. At the time the only option offered by the CAP spec was the iTIP approach (not real-time). Customers were not enthused about this approach and deficiency in CAP.
Later, we posed the SEARCH/VQUERY concept. It got a cool reception. The response was that "it seems like a step backward" compared with the simplicity of an iTIP request. We assured them the spec was not yet final and something better might be forthcoming.
After implementing the CAP iTIP-VFREEBUSY request/response, the idea of using a VFREEBUSY request 'directly' occurred to us. We implemented it as an X-GETFREEBUSY command. Implementation was very quick because it leveraged the already existing iTIP-VFREEBUSY code.
When presented to customers the response was universally positive and enthusiastic! "That's more like it." "That makes much more sense." The simplicity and consistency with iTIP were also positives. Considering the previous alternatives, these customers urged us to lobby the CalSch WG to adopt this method of requesting free-busy information. They would very much like to see it in the spec so they can deal with other CAP implementations in a similar manner.
The proposal for using VFREEBUSY (dtstart, dtend) to request free-busy information is not a recent idea. It has been implemented, adopted and in use for over two months. The experience has been very good at both ends.
Our experience has been compelling. In sharing this narrative I’m hoping the WG can benefit from our experience and from the response of CAP adopters… and that it might be compelling to the WG at-large. If presented a choice, I am confident potential CAP adopters would choose the 'VFREEBUSY request' over 'VQUERY request' by a significant majority.
I see no problem offering both in the spec. While some call it as unnecessary, our experience indicates otherwise. Why not give adopters two ways to "get a cart up a hill"? Adopters can choose whether they want to "push it by hand" or "pull it with a truck". Let's give them a "truck". It's what they want.