Patricia Egen, Patricia Egen Consulting

1. An Introduction to Calendaring Standards – How it all started Patricia Egen, Patricia Egen Consulting Interop Manager and Individual Member, Calendaring and Scheduling Consortiumpregen@calconnect.org

2. Agenda Standards – what are they Standards Organizations The IETF Examples of Calendaring Needs Calendar Standards Where Next?

3. 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:

4. 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: http://strategies.ic.gc.ca/SSG/ca01579e.html

5. 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.

6. 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

7. 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

8. The IETF • 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.

9. Source – http://www.iso.org

10. 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: http://hotwired.lycos.com/webmonkey/00/08/index2a_page5.html?tw=commentary

11. 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.

12. 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.

13. 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

14. 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.

15. 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

16. iCalendar 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.

17. iTIP 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.

18. iMIP 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.

19. 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.

20. 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.

21. 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.

22. 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

24. 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. • EVERYONE!

25. Questions?