An Introduction to Calendaring Standards – How it all started. Patricia Egen, Patricia Egen Consulting Interop Manager and Individual Member, Calendaring and Scheduling Consortium [email protected] Agenda. Standards – what are they Standards Organizations The IETF
Standards – what are they
Examples of Calendaring Needs
Three phase rules supreme
In almost all areas, power is generated and distributed as a three phase supply. Only the voltage, frequency, and end presentation differ. Further than that, the world breaks down into two camps, which are basically:
Single phase Three phase Examples where used
voltage voltage 115V 208V USA, Canada, Hawaii
230V 415V Europe, Australia, New Zealand
This means when you travel overseas or vice versa, you need to carry adaptors to manage voltage and end presentation (the plugs). It’s the same with calendar products today. Just replace interfaces and underlying code with voltage and end presentation. In many cases, you can’t even get them to talk together.
International Electrotechnical Commission (IEC)
International Organization for Standardization (ISO)
Institute of Electrical and Electronics Engineers (IEEE)
American National Standards Institute (ANSI)
Internet Standards Groups
One author in a recent article stated the following regarding the speed of getting standards through the IETF:
“One thing that becomes clear when you compare the IETF and the W3C is that the IETF rarely considers anything a standard unless it has been in existence for a dozen years and is widely implemented and working. This is an outgrowth of the Internet's frontier days, when the most important thing was "rough consensus and working code" and the best guiding principle available to a developer wishing to implement an RFC was to "be conservative in what you do and liberal in what you accept from others." The IETF strongly believes that minor differences between competing implementations will eventually be smoothed out, at which time is it proper to consider something a standard.” **
Now, the speed of the internet and the increasing number of private and public parties developing products has made the process even slower. Reaching consensus is getting harder and competitors are vying for market share. The push for standards needs to come from the User community, not from the vendors. Money will always talk – even when it comes to standards.
** Source: http://hotwired.lycos.com/webmonkey/00/08/index2a_page5.html?tw=commentary
Defining standards for calendars is complicated because Calendaring and Scheduling is complicated.
It’s not as simple as defining an email envelope, addressing it, storing it in post office and then mailing it, sending back a reply.
Calendars involve time and time zones, recurring events, alarms, people, resources, events, searching times and resources on more in more than one place, blocking out time, suggesting time slots, and many, many more complexities that dwarf what email standards had to accommodate.
The following slides will attempt to show just a few examples of calendaring and scheduling needs.
a] A doctor wishes to keep track of all his appointments.
Need: Read and manipulate one's own calendar with only one CUA.
b] A busy musician wants to maintain her schedule on an internet-based agenda which she can access from anywhere.
Need: Read and manipulate one's own calendar.
c) A software development team wishes to share agenda information by using a group scheduling product in order to more effectively schedule their time.
Need: Share calendar information with users using the same calendar service.
d] A teacher wants his students to be able to book time slot during his office hours.
Need: Schedule calendar events and todos with users using the same calendar service.
e] A movie theatre wants to publish its schedule so that prospective customers can easily access it.
Need: Share calendar information with users using other calendar services, possibly from different vendors.
f] A social club wants to be able to organize events more effectively by booking time with its members.
Need: Schedule calendar events and todos with users using other calendar services, possibly from different vendors.
g) A corporation merges with another organization. Both have different calendar and scheduling systems but the organization does not have time to “merge” the two systems.
Need: The ability to interoperate between the two calendar systems
In the previous examples, the first four calendar needs can be satisfied through proprietary solutions, but the last three cannot.
From these needs we can establish that protocols are required for accessing information in a calendar store (where calendar data resides), and for scheduling events and todos.
In addition these protocols require a data format for representing calendar information.
Now it’s time to talk about calendaring standards.
iCalendar (iCAL) is the Language to be used in calendar events or, in other words, it’s how you describe the data in your calendar
It provides data format for representing calendar information which the other protocols can use. iCAL can also be used in other contexts such as a drag and drop format or an export/import format.
All the other protocols depend on ICAL, so all elements of a standards-based calendaring and scheduling systems will have to interpret ICAL. It will be the heart of all calendaring efforts.
ITIP is the scheduling protocol
ITIP describes the messages used to schedule calendar events. These messages are represented in ICAL, and have semantics (terminology) that include such things as being an invitation to a meeting, an acceptance of an invitation or the assignation of a task.
ITIP messages are used in the scheduling work flow, where users exchange messages in order to organize things such as events and todos. CUAs generate and interpret ITIP messages at the direction of the calendar user.
With ITIP one can create, modify, delete, reply to, counter, and decline counters to, the various ICAL components. Furthermore, one can also request the freebusy (open or busy) time of other people.
IMIP is a definition that tells how to attach or bind calendar objects to email. It uses the iTIP protocol to define the calendar objects and MIME to transport the mail.
While iMIP tells how to send a calendar object over email, CAP will provide a second real-time binding of ITIP, allowing CUAs (calendar programs and interfaces) to perform calendar management as well as scheduling over a single connection. In other words, direct into a calendar server instead of using email.
CAP is the calendar management protocol. It describes the messages used to manage calendars. These messages are represented in ICAL, and have semantics (or interpretations) such as a search for data, data in response to a search or the creation of a meeting.
CAP describes the messages used to manage calendars on a calendar store. A calendar store is a data storehouse of a calendar service. A calendar service may have several calendar stores, and each store may contain several calendars, as well as properties and components outside of the calendars.
These messages are represented in ICAL. With these messages one can do the operations in ITIP and other operations relating to a calendar store. These operations include, search, creating calendars, specifying calendar properties, and being able to specify access rights to one's calendars.
CAP also provides a real-time binding for the calendar management messages.
Webdav is document versioning on the web.
CalDav is using HTTP and WebDAV as a basis for a calendaring server
It is a standard way of modeling calendar data in WebDAV, plus some additional features to make calendar access work well.
There are several organizations who have developed CalDav servers and clients. This protocol has a good chance of actually being implemented.
It is currently in the development phase as an IETF draft.
RFC822 is the master rule book for describing an email object.
RFC822 in email = iCAL in Calendaring
POP or Post Office Protocol is the standard that describes repositories for storage and further transmission of email objects.
POP/IMAP in email = CAP in calendaring
iMIP uses RFC822 since iMIP defines how to send a calendar object
RFC822 is a wrapper for email = iTIP is a wrapper for calendaring objects