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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/