slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Patricia Egen, Patricia Egen Consulting PowerPoint Presentation
Download Presentation
Patricia Egen, Patricia Egen Consulting

Loading in 2 Seconds...

play fullscreen
1 / 25

Patricia Egen, Patricia Egen Consulting - PowerPoint PPT Presentation

  • Uploaded on

An Introduction to Calendaring Standards – How it all started. Patricia Egen, Patricia Egen Consulting Interop Manager and Individual Member, Calendaring and Scheduling Consortium Agenda. Standards – what are they Standards Organizations The IETF

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Patricia Egen, Patricia Egen Consulting' - maylin

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

An Introduction to Calendaring Standards –

How it all started

Patricia Egen, Patricia Egen Consulting

Interop Manager and Individual Member, Calendaring and Scheduling



Standards – what are they

Standards Organizations


Examples of Calendaring Needs

Calendar Standards

Where Next?


What are Standards?

  • Common Protocols, languages and terminology
    • Who speaks first, and how, and when.
    • Descriptions and definitions that all parties agree to use.
    • Common definition of data
    • This is a name, this is an address, this is a date, this is a time zone, etc.
    • A Way to make things work together
  • What do software standards try to solve?
    • Interoperability, portability, data exchange
  • Here are some common standards you may (or may not) recognize:

Standards also are….

  • Technical specifications or other criteria that a product, process or service must meet. Standards provide information to consumers, manufacturers and retailers, and enhance safety, reliability and performance of the products, processes and services consumers use. Standards assure consumers about reliability or other characteristics of services provided in the marketplace. Standards also give consumers more choice by allowing one firm's products to be substituted for, or combined with, those of another.
  • To be credible, standards must have certain attributes:
  • their development must be overseen by a recognized body
  • the development process must be open to input from all interested parties
  • the resulting standards must be documented and publicly available
  • there is usually a method for monitoring and verifying that organizations are complying with standards.
  • Source:
an example of how standards affect you world power standards
An example of How Standards Affect You – World Power Standards

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.


Some Key Standards Bodies

International Electrotechnical Commission (IEC)

  • Responsible for electrical, electronic and related Technologies

International Organization for Standardization (ISO)

  • Responsible for some standards not covered by the IEC

Institute of Electrical and Electronics Engineers (IEEE)

  • Not a standards group - strong role in technical standards setting, and often works with the formal standards organizations

American National Standards Institute (ANSI)

Industry Groups

Internet Standards Groups


Internet Governing Bodies

  • -The Internet Society (ISOC) - concerned with growth and evolution of the worldwide Internet, the way in which the Internet is and can be used, and with the social, political, and technical issues which arise as a result. The ISOC Trustees are responsible for approving appointments to the IAB from among the nominees submitted by the IETF nominating committee.
  • The IAB is a technical advisory group of the ISOC. It is chartered to provide oversight of the architecture of the Internet and its protocols, and to serve, in the context of the Internet standards process, as a body to which the decisions of the IESG may be appealed. The IAB is responsible for approving appointments to the IESG from among the nominees submitted by the IETF nominations committee.
  • The IESG is responsible for technical management of IETF activities and the Internet standards process. As part of the ISOC, it administers the process according to the rules and procedures which have been ratified by the ISOC Trustees. The IESG is directly responsible for the actions associated with entry into and movement along the Internet "standards track," including final approval of specifications as Internet Standards.
  • - The Internet Engineering Task Force


  • The IETF has evolved to provide technical guidance and standards development for the good of the Internet user community.
  • It is a unique and dynamic structure for the solving of technical problems. Anyone can belong and proprietary interests are not entertained as solutions. All standards are made freely available and working code is the key to success.
    • Develops and maintains some commonly used Internet standards.
    • Proposals are discussed as Internet-Drafts in committees.
    • Working implementations are usually provided.
    • After Internet-Drafts are refined and rough consensus achieved, they may be published as Requests for Comments (RFCs).
    • RFCs may become a proposed standard or may be published as informational documents, best current practices guidelines, or experimental standards
  • The IETF is divided into eight functional areas.
    • Applications, Internet, IP: Next Generation, Network Management, Operational Requirements, Routing, Security, Transport and User Services.
    • Each area has one or two area directors. The area directors, along with the IETF/IESG Chair, form the IESG.
standards take time
Standards Take Time

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:


Now Let’s Talk Calendars

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.


Calendar Examples – Part 1

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.


Calendar Examples – Part 2

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


Standards for Calendars

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.


Calendar Standards and Drafts Today

  • Internet Calendaring and Scheduling Core Object Specification (iCalendar) – RFC2445
  • iCalendar Transport-Independent Interoperability Protocol (iTIP) – RFC2446
  • iCalendar Message-Based Interoperability Protocol (iMIP) – RFC2447
  • Calendar Access Protocol (CAP) – now an Experimental RFC
  • CALDAV – in progress – not yet an RFC


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– Calendar

Access Protocol

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.


Why is CAP Important

  • There are two main methodologies for communicating iCalendar objects:
    • Use a store-and-forward mechanism such as email or
    • Via an on-the-wire mechanism (directly connected, however briefly), using the CAP specification.
  • Here’s just one example of needing CAP or CALDAV.
  • If I have a mobile device such as a PDA or a phone, I don’t necessarily want to send an email to that device with calendar data. Rather, I’d like to have it communicate directly with my calendar server (or store). That’s item #2 above!
  • CAP was the next big thing – however, it stalled. CALDAV is now gaining momentum.
what is caldav
What is CalDav?

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.


Comparing Calendar to

Email Standards

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


Who Needs Calendar Standards?

  • Anyone wanting to share their calendar with others
  • Anyone wanting to schedule meetings within and without their organization
  • Anyone wanting to schedule having an appliance repaired or getting milk delivered every Monday
  • Anyone wanting to schedule Just in Time delivery of parts
  • Anyone wanting to have calendar entries and alarms sent to their phone and handheld devices
  • Anyone who wants to stay on time.