Why can't we all share Free Busy Information?
Calendering is a human problem, made easier somewhat with Outlook and Exchange, but also made harder in how those programs have shifted our expectations on the ease of scheduling people and resources. Perhaps my largest frustration with Exchange and Outlook is being unable to see Free Busy time of my customers, those with whom I most often need to schedule meetings.
Several companies have tried to solve this issue, allowing people to publish their calendars to centralized services, but these require constant synchronization and I haven't really found one that works too well. Not to mention, I still have to send someone my calendar location and they still have to decipher and mentally plot my availability, translating it to the format in Outlook's scheduling tab.
It seems, however, that this would be quite simple to resolve. A workable solution that is already built into the Outlook interface and takes care of synchronization and translation. In fact, much of the ground work has already been laid with Outlook Web Access. Did you know that you can access an xml rendition of anyone's busy free time in OWA using the following URL:
https://serverName/public/?Cmd=freebusy&start=2006-06-06T6:00:00Z&end=2006-06-06T018:00:00Z&interval=15&u=SMTP:SomeUser@yourCompany.com
This is how OWA provides Free Busy to users when scheduling appointments from the browser client. The format of the output looks quite similar to the 001011000111 format that Outlook uses through the MAPI interface.
<a:response xmlns:a="WM">
<a:recipients>
<a:item>
<a:displayname>Selected User</a:displayname>
<a:email type="SMTP">UserName@yourCompany.com</a:email>
<a:type>1</a:type>
<a:fbdata>11110000000000022201100001100</a:fbdata>
</a:item>
</a:recipients>
</a:response>
Today, however, such information is only available for other folks in your organization, so the work put into this feature is largely underutilized. But then again, it was designed to solve a different problem.
It would seem to me that if such information is available as a URL, it could be made available as a Web Service. If I wanted to share my Exchange-based busy-free time with customers, I could send them my contact information (in Outlook Contact Format), which would include a special field called something like Free-Busy Service Locator (FBSL). When my customers schedule meetings with me, their Outlook client would know where to find my free-busy information, make the request to the URL specified and plot my time alongside their own and others local to their Exchange environment. How many phone calls did I just save?
What exactly would this require? I will leave that to the devs, but from a high level:
- Outlook Contacts will need to be updated with an additional field for Free Busy Web Service Link and Outlook would need to know how to use that data, if and when present for external contacts.
- Exchange Front-end servers would need to provide anonymous access (without logon prompts or forms-based authentication) to the folder where the service would reside.
- Organizations wishing to participate in a connected community would have to activate the feature on their Exchange front-end servers.
- Outlook, or Exchange, would need to have a function that provides, on a per user or policy basis, permission from users to have their busy-free data published (since not everyone will want this). It also needs a way to communicate the FBSL URL back to the owner of the busy free data so he can share it with others.
Comments
Anonymous
June 05, 2006
This problem is solved. See
http://ifreebusy.com
and
http://ifreebusy.com/help/guides/pc_outlook_2003.html
Sure it will be great if Microsoft will provide this service in calendar.live.com Anthony Says:
If what I read is true, this does not solve the problem because you still need to manually syncronize your calendar data.Anonymous
July 02, 2006
The comment has been removedAnonymous
August 23, 2007
While ifreebusy.com is complex and unfriendly, http://www.timebridge.com provides a clean way to not only share free/busy, but also to schedule meetings across calendaring systems ANTHONW: This is either an advertisement or a misunderstanding of the problem I am trying to address. I don't want a third party solution that relies on synchronization. I want access to the sources. Not saying that this or any other third party solution won't work or isn't appropriate; just saying that its not addressing the specific concern.