WEBDAV Working Group Surendra Reddy Internet Draft Oracle Corporation draft-ietf-webdav-enpreq-00.txt April 16, 1998 Expires October 16, 1998 Requirements for Event Notification Protocol 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 and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WEBDAV) working group at <w3c-dist-auth@w3.org>, which may be joined by sending a message with subject "subscribe" to <w3c-dist-auth-request@w3.org>. Discussions of the WEBDAV working group are archived at <URL:http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>. Abstract This document describes the requirements for an Event Notification Protocol. The objective is to provide a simple, scalable and highly efficient notification protocol while also providing the appropriate flexibility to meet the needs of both the internet and enterprise environments. Intent of this document is to collect all notification requirements in one place and leverage the work already done in other working groups. This document is one of a set of documents which together describe all aspects of a new Event Notification Protocol (ENP). ENP is an application level protocol that can be used for distributed event S.Reddy [Page 1]
draft-ietf-webdav-enpreq-00.txt April 1998 notification. The full set of ENP documents include: (1). Requirements for Event Notification Protocol (2). Model and Semantics Event Notification Protocol (3). Protocol Specification for Event Notification Protocol (4). Rationale for the Structure and Model for the Event Notification Protocol 1. Introduction In a distributed authoring and versioning environment, user may want to monitor the changes performed on various resources created or owned by the user. Similarly, if a PROPFIND operation takes more time to complete the operation, client can choose to register this event to notify the client when the server finishes the PROPFIND rather than client waiting for the server to complete the task. Similarly, if any search operation in DASL takes more time in exe- cuting the search, client can register the event with the server so that sever notifies the client when the search is done. These requirements mandate the need for a mechanism to notify events to subscribed users. There are several different network event notification protocols like CORBA Event Services, X Window System events, SGAP, BSCW, etc. But these services are defined to work with specific architectures and impose large codebase which makes it practically difficult for lightweight notification services. This document presents a list of features in the form of require- ments for a Event Notification Protocol which, if implemented, would improve the efficiency of common event notification mechanisms for Distributed Authoring and Versioning protocol. 2. Terminology Supplier Events Supplier events generates event data. Consumer Events Consumer events process event data. Push Model S.Reddy [Page 2]
draft-ietf-webdav-enpreq-00.txt April 1998 In the Push model, Event Notification Protocol push event data to consumers. Pull Model In Pull model, consumers pull event data from Event Notification Protocol. 3. Event Notification Protocol 3.1. Overview Event Notification Protocol decouples the communication between communicating processes or events. The event notification protocol defines two roles for the events: the supplier roles and the con- sumer role. Suppliers produce event data and consumers process event data. Event data are communicated between suppliers and con- sumers through Event Notification Protocol(ENP). Event Notifica- tion Protocol uses push and pull model to initiates communication. The push model allows a supplier of events to initiate the transfer of the event data to consumers. The pull model allows a consumer of events to request the event data from a supplier. In the push model, the supplier is taking the initiative; in the pull model, the consumer is taking the initiative. The consumer may use either a blocking or non-blocking mechanism for receiving notifications. The consumer can periodically poll the channel for events. 3.2. Examples (1). The Event Notification Protocol can be used to generate change triggers. When a resource properties or contents are changed, ENP generates events and propagates to all subscribed parties. (2). Collection may be composed of internal and external members. Document authors are interested in knowing when the value of cer- tain properties or contents of these members have changed. Event Notification Protocol can be used to notify all such changes to all subscribed parties and document authors. 4. Requirements 4.1. Notification Registration It SHOULD be possible for end users to "register" for notifica- tions of certain types of events. S.Reddy [Page 3]
draft-ietf-webdav-enpreq-00.txt April 1998 4.2. Notification Attributes: It SHOULD be possible to associate attributes with the notifica- tion request. 4.3. Queued Notification Notifications which are not necessarily sent immediately, but are queued for delivery some intermediate network process or for later retrieval. 4.4. Notification with Reliable Delivery It SHOULD be possible to deliver event notifications in a reliable manner, assuring fully ordered end-to-end delivery. Guaranteed delivery requires both queued notification and a reliable tran- sport. 4.5. Notifications with Unreliable Delivery Notifications are delivered via the fundamental transport address and routing framework, but no acknowledgement or retry is required. Process to process communications, if involved, are unconstrained. 4.6. Quality of Service Some notification delivery methods may allow users to select qual- ity of service parameters. These parameters will depend upon the specific delivery method chosen and may include parameters such as priority, security, number of retries, and the like. 4.7. Consumers must be able specify zero or more notification recipients when submitting an event. When specifying a notifica- tion recipient, consumers must be able to specify notification delivery method, associated attributes and any other quality of service parameters for the notification recipient. 4.8. It SHOULD be possible to deliver an event notification through firewalls. However, it need not test to guarantee delivery of the notification through a firewall before accepting the event registration request. 4.9. A mechanism must be provided for delivering notification to the submitting client when the delivery of an event notification to a specified Notification Recipient fails. 4.10. Events work in a distributed environment. Consumers SHOULD be able either request events or be notified of events, whichever is more appropriate for application design and performance. S.Reddy [Page 4]
draft-ietf-webdav-enpreq-00.txt April 1998 4.11. A supplier can issue a single request to communicate event data to all consumers at once. 4.12. Supplier can generate events without knowing the identities of consumers. Conversely, consumers can receive events without knowing the identities of the suppliers 4.13. Complex events may be handled by constructing tree of event consumers/suppliers checking for successively more specific event predicates. 4.14. Consumers and suppliers SHOULD be able to register with event channels. 4.15. It SHOULD be possible to support event filtering through which event channels deliver events selectively from suppliers to consumers. 4.16. Some applications may require that consumers of an event provide an explicit confirmation of reception back to the sup- plier. 4.17. It SHOULD be possible to consume events from one or more suppliers and supplies events to one or more consumers. 4.18. Some applications may require that consumers of an event provide an explicit confirmation of reception back to the supplier. Event Notification Protocol SHOULD be able to support this functionality effectively using event attributes. 5. Extensibility The Event Notification Protocol shall be extensible to facilitate interoperability and prevents implementation collisions. 6. Security Requirements 6.1. It SHOULD be possible to digitally sign the notifications to ensure the integrity of the notifications or origin of the event notifications. 6.2. It SHOULD be possible that the Event Notification Protocol to operate within a secure environment. Wherever possible ENP SHOULD be able to make use of existing security protocols and services. ENP SHOULD not invent new security protocols or services if the requirements described in this document can be met by existing protocols and services. S.Reddy [Page 5]
draft-ietf-webdav-enpreq-00.txt April 1998 6.3. ENP shall by definition support event registration and notification from one enterprise to another through firewalls. ENP must be capable of passing through firewalls and/or proxy servers(where enabled by the firewall administrator) preferably without any modifications to the existing firewall technology. 7. Internationalization 7.1. As consumer and producers of events come from all over the world, Event Notification Protocol SHOULD meet internationaliza- tion and localization requirements. 8. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997 [3] Postel, Jonathon B., "SIMPLE MAIL TRANSFER PROTOCOL", RFC 821, August 1982 [4] Postel, J., and Reynolds, J., "FILE TRANSFER PROTOCOL (FTP)", RFC 959, October 1985 [5] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [6] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. Jen- sen, "Extensions for Distributed Authoring on the World Wide Web - WebDAV.", Draft-ietf-webdav- protocol-07.txt, February, 1998. 9. Author's Address Oracle Corporation 500 Oracle Parkway M/S 6op3 Redwoodshores, CA 94065 Phone: +1(650) 506 5441 Fax: +1(650) 654 6205 Email: skreddy@us.oracle.com Expires October 16, 1998 S.Reddy [Page 6]
