Network Working Group A. Ganguly Internet Draft: Real-time protocol requirements CSI March 1997 Expires 5-Oct-1997 Real-time Protocol Requirements Status of this memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress``. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the IESG as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire six months after publication. Distribution of this draft is unlimited. 1. Abstract: The purpose of this document is to create a framework for selecting the appropriate solution for a real-time protocol designed to allow calendaring and scheduling systems from different vendors to interoperate. To that end, it describes the assumptions about the context in which this protocol will operate, and the requirements that the protocol must meet. These requirements are not intended to apply to a companion protocol which will use E-mail based transport to achieve interoperability. The E-mail based protocol, which is the subject of a different document, will not make any assumptions about transport latency. Ganguly [Page 1] Internet Draft Real-time protocol requirements March 1997 2. Assumptions: 2.1. iCalendar It is assumed that events will be represented as iCalendar objects encoded using MIME. 2.2. iCalendar Profiles It is assumed that specific profiles have been defined for iCalendar so that each iCalendar object completely describes how a receiving calendar system should interpret the received object. The mechanism used to deliver the iCalendar object to the receiving system MUST not contain data that will affect the interpretation of the iCalendar object. 2.3. iCalendar Attendee identification It is assumed that iCalendar attendees are identified as RFC822 addresses. Further, for an individual we assume that this address is their e-mail address. 3. Requirements: 3.1. Bounded latency The protocol must be capable of returning a response to the requester (client) within a definite limited time (<60 seconds ???). A mechanism needs to exist to inform the client that a well formed request has been received within a limited time. This will be necessary to support exchanges where processing time on the receiver would exceed the definite limited time. 3.2. Simple The protocol should be simple to understand, debug and to implement on a variety of devices capable of connection to a IP internetwork. 3.3. Leverages existing, widely deployed Internet technologies Wherever possible, the protocol should reuse existing, widely deployed Internet technologies or popular conventions rather than invent a new technology unnecessarily. 3.4. Efficient for the particular task The protocol should efficiently handle the task it is designed to handle, establishing interoperability between calendaring and scheduling systems. As such, generality is not a goal for this protocol. Ganguly [Page 2] Internet Draft Real-time protocol requirements March 1997 3.5. Scaleable The protocol should be designed to handle communication from any Internet node to any other Internet node, that is, it should support an unbounded number of users and servers. The protocol should support an unbounded number of servers per domain. A domain is a part of the address as defined in RFC822. The protocol should be designed to handle a large number of calendars (i.e. users, resources, etc.) per server. 3.6. Secure The protocol should be designed to ensure that the communicating nodes are who they are supposed to be. The protocol should be designed to enable private communication between nodes. The protocol should be designed to work well with and be deployed in conjunction with existing firewall technology. 3.7. Server address resolution The protocol should define the mechanism that the client will use to locate the appropriate servers corresponding to the attendee addresses contained in the iCalendar object that is submitted for transport. 3.8. Easy deployment and administration The protocol should be easily deployed within the existing Internet infrastructure. That is, it should not require substantial new technology or administrative overhead or cause incompatibilities with existing technology. In fact, it should fit well into the existing infrastructure. 4. Acknowledgments: Thanks to the following people for helpful comments on an earlier draft: Einar Stefferud, Derik Stenerson, Frank Dawson and Steve Hanna. 5. Author's Address: Anik Ganguly Campbell Services, Inc. 21700 Northwestern Highway, 10th Floor Southfield, MI 48075 USA Email: anik@ontime.com Document expires: 5-Oct-1997 Ganguly [Page 3]