Calendaring and scheduling - X.400 API Assn.'s efforts for developing group calendar/scheduler communications standards, IBM's Vendor Independent Calendaring specification and the potential impacts of General Magic's Telescript smart messaging technology - one of several articles on Personal Data Interchange technologies - includes related articles on cross-platform calendaring scenario and Telescript

RELease 1.0, Sept 23, 1993 by Jerry Michalski

Because it is more conversational than exchanging business cards (can you meet next Tuesday? no, I'm on deadline, but maybe Wednesday), calendaring personal data interchange is significantly more complicated. It requires looking up free time, setting tentative meetings and dealing with multiple attendees. Worse still, today's group-calendaring systems work only with static desktop computers. People on the move usually print a copy of their schedule and authorize an assistant to act as their proxy. When they return, they have to reconcile all the meetings hooked in the meantime.

Gotta play with the pocket pals

Handhelds, especially combined with wireless communications, are essential to the long-term success of group calendaring because they will put mobile workers on the same footing as those sitting at their pcs. Resolving questions right away eliminates a huge amount of downstream activity.

Calendaring-system software vendors might hope to compete only against each other, but that is quickly changing. Many of the vendors we have mentioned so far offer calendaring. Newton, the HP pocket computers, EO, Zooruer and other handhelds all have built-in schedule minders. And PIN vendors, originally focused exclusively on personal productivity, are extending their calendar features onto the corporate network. We hope eventually there will be open time servers, Just as there are open message servers today.

The group calendarins and scheduling market is large and growing, and may be the subject of a future issue of Release 1.0. However. here we focus on the standards efforts afoot, emphasizing the role that handheld devices play and the effect that Telescript will have.

As with PIMs. interoperability hasn't been a big driver for vendors of group-calendaring systems. But they have shown more energy and initiative, as evidenced from presentations at a recent meeting hosted by the XAPIA.

The XAPIA asks the right questions

The X.400 API Association (XAPIA)(4) recently held an open. one-day workshop to assess whether it should get involved in developing common communication standards for group calendar/scheduler applications; the answer was "yes." While it may seem suspect for a group formed to promote X.400 e-mail messaging to play the role of unbiased intermediary in an issue that clearly has other solutions, the XAPIA has actually proven itself quite honorable. The group took less than a year to defuse the MAPI/VIM (read: Microsoft/Lotus) e-mail message-protocol wars, which led to its publishing the Common Messaging Calls.

True, XAPIA has an e-mail bias and there were no PIM representatives at the workshop, but the Association seems to be the best bet as a forum for PDI discussions on calandaring. The standards presented at the workshop are likely to influence XAPIA's course over the next year.

One of those efforts was by three calendaring-system vendors that are part of the MHS Alliance: Microsystems Software's (CaLANder), Campbell Services' (OcTline) and ON Technology (Meeting Maker). (ON recently merged with Notework, a LAN desktop-message TSK vendor.) Since they share MHS as a transport. the three companies have already agreed on interchange protocols.

Necessity. the mother of needed software protocols

Some interoperability efforts are driven by customer demand. For example, an IBM team responded to customers looking to hook production applications to IBM's Time and Place/2 by developing protocols that the company has generalized (to avoid an IBM bias) and published as VIC, the Vendor Independent Calandaring specification. IBM is offering VIC to standards committees for consideration.

Proposed by Ric Telford of IBM's software lab in Westlake, Texas, VIC is a calendar-enabling interface API -- it makes applications calendar-aware, as VIM does with massaging.5 For example, when a customer calls a voice-response system to report a service problem, the application could use VIC to find free time in a field tech's schedule, then post the service call to that schedule.

Microsoft's calandaring efforts

Customers also precipitated some of Microsoft's efforts. At the XAPIA meeting, Bill Sornsin, Microsoft's product manager for enterprise massaging, described Microsoft's efforts to date, which have been mostly internally focused. Responding to similar customer requests, Microsoft created SPL, the Schedule Libraries for Visual Basic and C , which allow developers access to Schedule files.

As a way of moving toward collaboration within XAPIA, Sornsin proposed a practical, short-term solution for message-based calendar transactions: extending XAPIA's CMC protocols with five new message types -- request, accept, decline, negotiate and cancel a meeting.6 These messages would carry only minimal information needed to describe the appointments. This proposal is less ambitious than VIC, but it covers some of the same ground and piggybacks on XAPIA's success with CMC, which is already built into the next version of Windows.

What role for Telescript?