home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-calsch-rtreq-00.txt < prev    next >
Text File  |  1997-03-28  |  6KB  |  164 lines
  1. Network Working Group                    A. Ganguly
  2. Internet Draft: Real-time protocol requirements    CSI
  3. <ietf-calsch-rtreq-00.txt>                March 1997
  4. Expires 5-Oct-1997
  5.  
  6.  
  7.             Real-time Protocol Requirements
  8.  
  9. Status of this memo
  10.  
  11.   This document is an Internet Draft.  Internet Drafts are 
  12.   working documents of the Internet Engineering Task Force 
  13.   (IETF), its Areas, and its Working Groups.  Note that other 
  14.   groups may also distribute working documents as Internet 
  15.   Drafts.
  16.  
  17.   Internet Drafts are draft documents valid for a maximum of 
  18.   six months.  Internet Drafts may be updated, replaced, or 
  19.   obsoleted by other documents at any time.  It is not 
  20.   appropriate to use Internet Drafts as reference material or 
  21.   to cite them other than as a ``working draft'' or ``work in 
  22.   progress``.
  23.  
  24.   To learn the current status of any Internet-Draft, please 
  25.   check the 1id-abstracts.txt listing contained in the 
  26.   Internet-Drafts Shadow Directories on ds.internic.net, 
  27.   nic.nordu.net, ftp.isi.edu, or munnari.oz.au.
  28.  
  29.   A revised version of this draft document will be submitted 
  30.   to the IESG as a Proposed Standard for the Internet 
  31.   Community.  Discussion and suggestions for improvement are 
  32.   requested.  This document will expire six months after 
  33.   publication.  Distribution of this draft is unlimited.
  34.  
  35. 1. Abstract:
  36.   The purpose of this document is to create a framework for 
  37.   selecting the appropriate solution for a real-time protocol 
  38.   designed to allow calendaring and scheduling systems from 
  39.   different vendors to interoperate.  To that end, it 
  40.   describes the assumptions about the context in which this 
  41.   protocol will operate, and the requirements that the 
  42.   protocol must meet.
  43.  
  44.   These requirements are not intended to apply to a companion 
  45.   protocol which will use E-mail based transport to achieve 
  46.   interoperability.  The E-mail based protocol, which is the 
  47.   subject of a different document, will not make any 
  48.   assumptions about transport latency.
  49.  
  50. Ganguly                                              [Page 1]
  51.  
  52.  
  53. Internet Draft      Real-time protocol requirements    March 1997
  54.  
  55.  
  56. 2. Assumptions:
  57.  
  58. 2.1. iCalendar
  59.   It is assumed that events will be represented as iCalendar 
  60.   objects encoded using MIME.
  61.  
  62. 2.2. iCalendar  Profiles
  63.   It is assumed that specific profiles have been defined for 
  64.   iCalendar so that each iCalendar object completely describes 
  65.   how a receiving calendar system should interpret the 
  66.   received object.  The mechanism used to deliver the 
  67.   iCalendar object to the receiving system MUST not contain 
  68.   data that will affect the interpretation of the iCalendar 
  69.   object.
  70.  
  71. 2.3. iCalendar Attendee identification
  72.   It is assumed that iCalendar attendees are identified as 
  73.   RFC822 addresses.  Further, for an individual we assume that 
  74.   this address is their e-mail address.
  75.  
  76.  
  77. 3. Requirements:
  78.  
  79. 3.1. Bounded latency
  80.   The protocol must be capable of returning a response to the 
  81.   requester (client) within a definite limited time (<60 
  82.   seconds ???).  A mechanism needs to exist to inform the 
  83.   client that a well formed request has been received within a 
  84.   limited time.  This will be necessary to support exchanges 
  85.   where processing time on the receiver would exceed the 
  86.   definite limited time.
  87.  
  88. 3.2. Simple
  89.   The protocol should be simple to understand, debug and to 
  90.   implement on a variety of devices capable of connection to a 
  91.   IP internetwork.
  92.  
  93. 3.3. Leverages existing, widely deployed Internet 
  94.   technologies
  95.   Wherever possible, the protocol should reuse existing, 
  96.   widely deployed Internet technologies or popular conventions 
  97.   rather than invent a new technology unnecessarily.
  98.  
  99. 3.4. Efficient for the particular task
  100.   The protocol should efficiently handle the task it is 
  101.   designed to handle, establishing interoperability between 
  102.   calendaring and scheduling systems.  As such, generality is 
  103.   not a goal for this protocol.
  104.  
  105. Ganguly                                              [Page 2]
  106.  
  107.  
  108. Internet Draft      Real-time protocol requirements    March 1997
  109.  
  110.  
  111. 3.5. Scaleable
  112.   The protocol should be designed to handle communication from 
  113.   any Internet node to any other Internet node, that is, it 
  114.   should support an unbounded number of users and servers.
  115.  
  116.   The protocol should support an unbounded number of servers 
  117.   per domain.  A domain is a part of the address as defined in 
  118.   RFC822.
  119.  
  120.   The protocol should be designed to handle a large number of 
  121.   calendars (i.e. users, resources, etc.) per server.
  122.  
  123. 3.6. Secure
  124.   The protocol should be designed to ensure that the 
  125.   communicating nodes are who they are supposed to be.
  126.  
  127.   The protocol should be designed to enable private 
  128.   communication between nodes.
  129.  
  130.   The protocol should be designed to work well with and be 
  131.   deployed in conjunction with existing firewall technology.
  132.  
  133. 3.7. Server address resolution
  134.   The protocol should define the mechanism that the client 
  135.   will use to locate the appropriate servers corresponding to 
  136.   the attendee addresses contained in the iCalendar object 
  137.   that is submitted for transport.
  138.  
  139. 3.8. Easy deployment and administration
  140.   The protocol should be easily deployed within the existing 
  141.   Internet infrastructure. That is, it should not require 
  142.   substantial new technology or administrative overhead or 
  143.   cause incompatibilities with existing technology.  In fact, 
  144.   it should fit well into the existing infrastructure.
  145.  
  146. 4. Acknowledgments:
  147.   Thanks to the following people for helpful comments on an 
  148.   earlier draft:  Einar Stefferud, Derik Stenerson, Frank 
  149.   Dawson and Steve Hanna.
  150.  
  151. 5. Author's Address:
  152.   Anik Ganguly
  153.   Campbell Services, Inc.
  154.   21700 Northwestern Highway, 10th Floor
  155.   Southfield, MI  48075 USA
  156.  
  157.   Email:  anik@ontime.com
  158.  
  159.  
  160. Document expires: 5-Oct-1997
  161.  
  162. Ganguly                                                [Page 3]
  163.  
  164.