idnits 2.17.1 draft-ietf-webdav-enpreq-01.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-20) 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). -- 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 (November 1, 1998) is 9302 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) -- Looks like a reference, but probably isn't: 'RFC2044' on line 243 == Unused Reference: '1' is defined on line 247, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 250, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 257, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 260, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 263, 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 (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group Surendra Reddy(Oracle) 3 Internet Draft Mark Leighton Fisher(TCE) 4 draft-ietf-webdav-enpreq-01.txt May 1, 1998 5 Expires November 1, 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 . 34 Abstract 36 This document describes the requirements for an Event Notification 37 Protocol. The objective is to provide a simple, scalable and highly 38 efficient notification protocol while also providing the appropriate 39 flexibility to meet the needs of both the Internet and enterprise 40 environments. Intent of this document is to collect all notification 41 requirements in one place and leverage the work already done in other 42 working groups. 44 This document is one of a set of documents which together describe 45 all aspects of a new Event Notification Protocol (ENP). ENP is an 46 application level protocol that can be used for distributed event 47 notification. The full set of ENP documents include: 49 (1). Requirements for Event Notification Protocol 51 (2). Model and Semantics Event Notification Protocol 53 (3). Protocol Specification for Event Notification Protocol 55 (4). Rationale for the Structure and Model for the Event 56 Notification Protocol 58 1. Introduction 60 In a distributed environment, there will be operations thant take so 61 long that the user doesn't want to wait till the completion of the 62 event. For example, in a distributed authoring and versioning 63 environment, user may want to monitor the changes performed on vari- 64 ous resources created or owned by the user. Similarly, if a report 65 generation event takes significant amount of time to complete the 66 event, user can choose to be notified when the event completes 67 rather than constantly polling or waiting for the event to complete. 69 Similarly, if any search operation takes more time in executing the 70 search, client can register the event with the server so that sever 71 notifies the client when the search is done. These requirements man- 72 date the need for a mechanism to notify events to subscribed users. 74 There are several different network event notification protocols 75 like CORBA Event Services, X Window System events, SGAP, BSCW, etc. 76 But these services are defined to work with specific architectures 77 and impose large codebases which makes them in practice difficult to 78 use them in lightweight notification services. 80 This document presents a list of features in the form of require- 81 ments for a Event Notification Protocol which, if implemented, would 82 improve the efficiency of common event notification mechanisms. 84 2. Terminology 86 Events Supplier 87 Events Supplier generates event data. 89 Events Consumer 90 Events Consumer 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 the Event Notification Protocol(ENP). Event Notif- 109 ication Protocol can be initiated by either the push or pull model 110 in ENP. 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's properties or contents are 123 changed, ENP generates events and propagates these events all sub- 124 scribed parties. 126 (2). Collections may be composed of internal and external members. 127 Document authors are interested in knowing when the value of cer- 128 tain properties or the contents of these members have changed. 129 Event Notification Protocol can be used to send notifications of 130 all such changes to 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 for some intermediate network process or for 145 later retrieval. Queued notifications SHOULD be supported. 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(s). 166 recipients when submitting a request for event notification. When 167 specifying a notification recipient, consumers MUST be able to 168 specify notification delivery method, associated attributes and 169 any other quality of service parameters for the notification reci- 170 pient. 172 4.8. It SHOULD be possible to deliver an event notification 173 through firewalls. However, guaranteed delivery of the notifica- 174 tion through a firewall need not be tested before accepting the 175 event registration request. 177 4.9. A mechanism MUST be provided for delivering notification to 178 the submitting client when the delivery of an event notification 179 to a specified Notification recipient fails. 181 4.10. Events exist in a distributed environment. Consumers SHOULD be 182 able either request events(Subscription Model) or be notified of 183 events without subscribing(Broadcast Model), whichever is more 184 appropriate for application design and performance. 186 4.11. A supplier MAY issue a single request to communicate event 187 data to all consumers at once. 189 4.12. Supplier MAY generate events without knowing the identities 190 of consumers. Conversely, consumers MAY receive events without 191 knowing the identities of the suppliers 193 4.13. Complex events may be handled by constructing tree of events 194 consumers/suppliers checking for successively more specific event 195 predicates. 197 4.14. Consumers and suppliers SHOULD be able to register with event 198 channels. 200 4.15. It SHOULD be possible to support event filtering through 201 which event channels deliver events selectively from suppliers to 202 consumers. 204 4.16. Some applications may require that consumers of an event 205 provide an explicit confirmation of reception back to the sup- 206 plier. 208 4.17. It SHOULD be possible to consume events from one or more 209 suppliers and supplies events to one or more consumers. 211 4.18. Some applications may require that consumers of an event provide 212 an explicit confirmation of reception back to the supplier. Event 213 Notification Protocol SHOULD be able to support this functionality 214 effectively using event attributes. 216 5. Extensibility 217 The Event Notification Protocol SHALL be extensible to facilitate 218 interoperability and prevent implementation collisions. 220 6. Security Requirements 222 6.1. It SHOULD be possible to digitally sign the notifications to 223 ensure the authenticity and integrity of the notifications. 225 6.2. It SHOULD be possible for the Event Notification Protocol to 226 operate within a secure environment. Wherever possible ENP SHOULD 227 be able to make use of existing security protocols and services. 228 ENP SHOULD NOT invent new security protocols or services if the 229 requirements described in this document can be met by existing 230 protocols and services. 232 6.3. ENP SHOULD support support event registration and 233 notification from one enterprise to another through firewalls. 234 ENP MUST be capable of passing through firewalls and/or proxy 235 servers(where enabled by the firewall administrator) preferably 236 without any modifications to the existing firewall technology. 238 7. Internationalization 240 7.1. As consumer and producers of events come from all over the 241 world, Event Notification Protocol SHOULD meet internationaliza- 242 tion and localization requirements. Because of these requirements, 243 ENP SHOULD use UTF-8[RFC2044] as its native character set. 245 8. References 247 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 248 Levels", BCP 14, RFC 2119, March 1997 250 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and Berners-Lee, 251 T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 252 1997 254 [3] Postel, Jonathon B., "SIMPLE MAIL TRANSFER PROTOCOL", RFC 821, 255 August 1982 257 [4] Postel, J., and Reynolds, J., "FILE TRANSFER PROTOCOL (FTP)", RFC 258 959, October 1985 260 [5] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 261 2277, January 1998. 263 [6] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. Jen- 264 sen, "Extensions for Distributed Authoring on the World Wide Web - 265 WebDAV.", Draft-ietf-webdav- protocol-08.txt, April 7, 1998. 267 9. Author's Address 269 Surendra Reddy 270 Oracle Corporation 271 500 Oracle Parkway 272 M/S 6op3 273 Redwoodshores, CA 94065 274 Phone: +1(650) 506 5441 275 Fax: +1(650) 654 6205 276 Email: skreddy@us.oracle.com 277 Mark Leighton Fisher 278 Thomson Consumer Electronics 279 Indianapolis, IN 280 email: fisherm@indy.tce.com 282 Expires November 1, 1998