idnits 2.17.1 draft-skreddy-enpreq-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 1998) is 9317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 245, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 248, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 252, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 255, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 258, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 261, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (ref. '2') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 821 (ref. '3') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group Surendra Reddy 3 Internet Draft Oracle Corporation 4 draft-skreddy-enpreq-00.txt April 16, 1998 5 Expires October 16, 1998 7 Requirements for Event Notification Protocol 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or made obsolete by other documents at 18 any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. Please send comments to 28 the Distributed Authoring and Versioning (WEBDAV) working group at 29 , which may be joined by sending a message with 30 subject "subscribe" to . 32 Discussions of the WEBDAV working group are archived at 33 . 35 Abstract 37 This document describes the requirements for an Event Notification 38 Protocol. The objective is to provide a simple, scalable and highly 39 efficient notification protocol while also providing the appropriate 40 flexibility to meet the needs of both the internet and enterprise 41 environments. Intent of this document is to collect all notification 42 requirements in one place and leverage the work already done in other 43 working groups. 45 This document is one of a set of documents which together describe 46 all aspects of a new Event Notification Protocol (ENP). ENP is an 47 application level protocol that can be used for distributed event 48 notification. The full set of ENP documents include: 50 (1). Requirements for Event Notification Protocol 52 (2). Model and Semantics Event Notification Protocol 54 (3). Protocol Specification for Event Notification Protocol 56 (4). Rationale for the Structure and Model for the Event 57 Notification Protocol 59 1. Introduction 61 In a distributed authoring and versioning environment, user may want 62 to monitor the changes performed on various resources created or 63 owned by the user. Similarly, if a PROPFIND operation takes more 64 time to complete the operation, client can choose to register this 65 event to notify the client when the server finishes the PROPFIND 66 rather than client waiting for the server to complete the task. 67 Similarly, if any search operation in DASL takes more time in exe- 68 cuting the search, client can register the event with the server so 69 that sever notifies the client when the search is done. These 70 requirements mandate the need for a mechanism to notify events to 71 subscribed users. 73 There are several different network event notification protocols 74 like CORBA Event Services, X Window System events, SGAP, BSCW, etc. 75 But these services are defined to work with specific architectures 76 and impose large codebase which makes it practically difficult for 77 lightweight notification services. 79 This document presents a list of features in the form of require- 80 ments for a Event Notification Protocol which, if implemented, would 81 improve the efficiency of common event notification mechanisms for 82 Distributed Authoring and Versioning protocol. 84 2. Terminology 86 Supplier Events 87 Supplier events generates event data. 89 Consumer Events 90 Consumer events process event data. 92 Push Model 93 In the Push model, Event Notification Protocol push event data to 94 consumers. 96 Pull Model 97 In Pull model, consumers pull event data from Event Notification 98 Protocol. 100 3. Event Notification Protocol 102 3.1. Overview 103 Event Notification Protocol decouples the communication between 104 communicating processes or events. The event notification protocol 105 defines two roles for the events: the supplier roles and the con- 106 sumer role. Suppliers produce event data and consumers process 107 event data. Event data are communicated between suppliers and con- 108 sumers through Event Notification Protocol(ENP). Event Notifica- 109 tion Protocol uses push and pull model to initiates communication. 110 The push model allows a supplier of events to initiate the 111 transfer of the event data to consumers. The pull model allows a 112 consumer of events to request the event data from a supplier. In 113 the push model, the supplier is taking the initiative; in the pull 114 model, the consumer is taking the initiative. 116 The consumer may use either a blocking or non-blocking mechanism 117 for receiving notifications. The consumer can periodically poll 118 the channel for events. 120 3.2. Examples 121 (1). The Event Notification Protocol can be used to generate 122 change triggers. When a resource properties or contents are 123 changed, ENP generates events and propagates to all subscribed 124 parties. 126 (2). Collection may be composed of internal and external members. 127 Document authors are interested in knowing when the value of cer- 128 tain properties or contents of these members have changed. Event 129 Notification Protocol can be used to notify all such changes to 130 all subscribed parties and document authors. 132 4. Requirements 134 4.1. Notification Registration 135 It SHOULD be possible for end users to "register" for notifica- 136 tions of certain types of events. 138 4.2. Notification Attributes: 139 It SHOULD be possible to associate attributes with the notifica- 140 tion request. 142 4.3. Queued Notification 143 Notifications which are not necessarily sent immediately, but are 144 queued for delivery some intermediate network process or for later 145 retrieval. 147 4.4. Notification with Reliable Delivery 148 It SHOULD be possible to deliver event notifications in a reliable 149 manner, assuring fully ordered end-to-end delivery. Guaranteed 150 delivery requires both queued notification and a reliable tran- 151 sport. 153 4.5. Notifications with Unreliable Delivery 154 Notifications are delivered via the fundamental transport address 155 and routing framework, but no acknowledgement or retry is 156 required. Process to process communications, if involved, are 157 unconstrained. 159 4.6. Quality of Service 160 Some notification delivery methods may allow users to select qual- 161 ity of service parameters. These parameters will depend upon the 162 specific delivery method chosen and may include parameters such as 163 priority, security, number of retries, and the like. 165 4.7. Consumers must be able specify zero or more notification 166 recipients when submitting an event. When specifying a notifica- 167 tion recipient, consumers must be able to specify notification 168 delivery method, associated attributes and any other quality of 169 service parameters for the notification recipient. 171 4.8. It SHOULD be possible to deliver an event notification 172 through firewalls. However, it need not test to guarantee delivery 173 of the notification through a firewall before accepting the event 174 registration request. 176 4.9. A mechanism must be provided for delivering notification to 177 the submitting client when the delivery of an event notification 178 to a specified Notification Recipient fails. 180 4.10. Events work in a distributed environment. Consumers SHOULD be 181 able either request events or be notified of events, whichever is 182 more appropriate for application design and performance. 184 4.11. A supplier can issue a single request to communicate event 185 data to all consumers at once. 187 4.12. Supplier can generate events without knowing the identities 188 of consumers. Conversely, consumers can receive events without 189 knowing the identities of the suppliers 191 4.13. Complex events may be handled by constructing tree of event 192 consumers/suppliers checking for successively more specific event 193 predicates. 195 4.14. Consumers and suppliers SHOULD be able to register with event 196 channels. 198 4.15. It SHOULD be possible to support event filtering through 199 which event channels deliver events selectively from suppliers to 200 consumers. 202 4.16. Some applications may require that consumers of an event 203 provide an explicit confirmation of reception back to the sup- 204 plier. 206 4.17. It SHOULD be possible to consume events from one or more 207 suppliers and supplies events to one or more consumers. 209 4.18. Some applications may require that consumers of an event provide 210 an explicit confirmation of reception back to the supplier. Event 211 Notification Protocol SHOULD be able to support this functionality 212 effectively using event attributes. 214 5. Extensibility 215 The Event Notification Protocol shall be extensible to facilitate 216 interoperability and prevents implementation collisions. 218 6. Security Requirements 220 6.1. It SHOULD be possible to digitally sign the notifications to 221 ensure the integrity of the notifications or origin of the event 222 notifications. 224 6.2. It SHOULD be possible that the Event Notification Protocol to 225 operate within a secure environment. Wherever possible ENP SHOULD 226 be able to make use of existing security protocols and services. 227 ENP SHOULD not invent new security protocols or services if the 228 requirements described in this document can be met by existing 229 protocols and services. 231 6.3. ENP shall by definition support event registration and 232 notification from one enterprise to another through firewalls. 233 ENP must be capable of passing through firewalls and/or proxy 234 servers(where enabled by the firewall administrator) preferably 235 without any modifications to the existing firewall technology. 237 7. Internationalization 239 7.1. As consumer and producers of events come from all over the 240 world, Event Notification Protocol SHOULD meet internationaliza- 241 tion and localization requirements. 243 8. References 245 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 246 Levels", BCP 14, RFC 2119, March 1997 248 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and Berners-Lee, 249 T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 250 1997 252 [3] Postel, Jonathon B., "SIMPLE MAIL TRANSFER PROTOCOL", RFC 821, 253 August 1982 255 [4] Postel, J., and Reynolds, J., "FILE TRANSFER PROTOCOL (FTP)", RFC 256 959, October 1985 258 [5] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 259 2277, January 1998. 261 [6] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. Jen- 262 sen, "Extensions for Distributed Authoring on the World Wide Web - 263 WebDAV.", Draft-ietf-webdav- protocol-07.txt, February, 1998. 265 9. Author's Address 267 Oracle Corporation 268 500 Oracle Parkway 269 M/S 6op3 270 Redwoodshores, CA 94065 271 Phone: +1(650) 506 5441 272 Fax: +1(650) 654 6205 273 Email: skreddy@us.oracle.com 275 Expires October 16, 1998