INTERNET DRAFT                                     J. Cohen, Microsoft
                                                S. Aggarwal, Microsoft
<draft-cohen-gena-client-00.txt>               Y. Y. Goland, Microsoft
Expires December, 1999                                   June 24, 1999

     General Event Notification Architecture Base: Client to Arbiter

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 obsoleted 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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This document provides for the ability to send and receive
   notifications using HTTP over TCP/IP and administratively scoped
   unreliable multicast UDP. Provisions are made for the use of
   intermediary arbiters, called subscription arbiters, which handle
   routing notifications to their intended destination.

1  Introduction

   This document provides for the sending of HTTP Notifications using
   administratively scoped unreliable Multicast UDP. Multicast UDP is
   useful in that it allows a single notification to be delivered to a
   potentially large group of recipients using only a single request.

   However administrative scoped unreliable Multicast UDP suffers from
   a number of problems including: how to route it, how to handle
   firewalling and how to deal with multiple scopes. This document only
   addresses the use of Multicast UDP within a single administrative
   scope and only countenances its use for scenarios where there is no
   notification proxy.

   In order to allow for notifications to be distributed beyond a
   single administrative multicast scope it is necessary to provide for
   relaying arbiters. These arbiters, called subscription arbiters, are
   able to form, through an unspecified mechanism, relationships with
   other subscription arbiters in order to distribute notifications.

Cohen et al.                                                  [Page 1]

INTERNET-DRAFT               GENA Client                June 24, 1999

   This allows a client to send a single HTTP notification to its
   subscription arbiter and have that notification forwarded on to one
   or more recipients. It is the subscription arbiter, not the client,
   who is responsible for maintaining the list of potential recipients
   and distributing notifications to those recipients.

   In order for subscription arbiters to know to whom to distribute
   notifications clients who wish to receive notifications, known as
   subscribers, must subscribe to the subscription arbiter.

2  Definitions

2.1 Event

   Any occurrence that may potentially trigger a notification.

2.2 Subscription

   An established relationship in which a resource has indicated
   interest in receiving certain notifications.

2.3 Subscriber

   A resource that negotiates a subscription with a subscription

2.4 Implied Subscriber

   A resource that did not negotiate a subscription with a subscription
   arbiter but will still be notified of events on that arbiter.

2.5 Notifying Resource

   A resource that issues notifications, for example, a subscription

2.6 Subscription Arbiter

   A resource that accepts subscriptions, receives notifications and
   forwards those notifications to its subscribers.

2.7 Notification

   A message sent by a notifying resource to provide notification of an

2.8 Notification Type

   A mechanism to classify notifications into categories. This allows
   subscribers to specify exactly what class of notifications they want
   to receive. It also allows notifying resources to specify what class
   of notification they are sending out.

Cohen et al.                                                  [Page 2]

INTERNET-DRAFT               GENA Client                June 24, 1999

   Notification types do not necessarily identify a single event but
   rather identify a group of related notifications. The notification
   sub-type is used to specify a particular event.

2.9 Notification Sub-Type

   Identification of a particular event within a notification type.

   For example, the fictional notification of type home:doors may
   contain notification sub-types such as door:open, close:door, etc.

   There is no requirement that the URI identifying the notification
   type and the URI identifying the notification sub-type have a
   syntactic relationship, only a semantic one.

2.10 Subscription ID

   A unique identifier for a subscription. Subscription Ids MUST be
   URIs and MUST be unique across all subscriptions across all
   resources for all time.

2.11 Scope

   Scopes are used in a subscription to indicate the notifying resource
   the subscriber is interested in.

3  Notification Model

   The notification model for GENA is based on the following picture:

   [Subscriber] <- [1+ Subscription Arbiters] <- [Notifying Resource]
       Notification Request         Notification Request
       Subscription Request

   Subscribers send subscription requests to their subscription
   arbiter. The arbiter will then forward to the subscriber any
   notifications it receives which match the subscriber's subscription.

   Notifying resources send notifications to their subscription arbiter
   to be passed on to subscribers.

   Subscription arbiters communicate with each other in order to pass
   along notifications and subscriptions. Subscription arbiter to
   subscription arbiter communication is out of scope for this

   For the purposes of this protocol all communication is between
   subscribers/notifying resources and their subscription arbiter. This
   does not preclude direct communication between a subscriber and a

Cohen et al.                                                  [Page 3]

INTERNET-DRAFT               GENA Client                June 24, 1999

   notifying resource. Rather it means that the notifying resource is
   acting as a subscription arbiter.

   This document also deals with a degenerate case where no
   subscription arbiter is available but administratively scoped
   unreliable multicast UDP facilities are. In that case provisions are
   made to allow a notifying resource to send its notifications
   directly to a previously agreed upon administratively scoped
   multicast UDP address where interested resources can listen in to
   the notification.

3.1 Sending HTTP Notifications through a Subscription Arbiter

   A notifying resource finds its subscription arbiter through an
   unspecified mechanism. The notifying resource will send all of its
   notifications to the subscription arbiter who will then forward
   those subscriptions on to subscribers.

   This document does not provide a mechanism by which the notifying
   resource can retrieve information about which resources have
   subscribed to receive notifications from the notifying resource.

3.2 Receiving HTTP Notifications through a Subscription Arbiter

   A subscribing resource finds its subscription arbiter through an
   unspecified mechanism. It is the responsibility of the subscribing
   resource to send subscription requests to the subscription arbiter
   in order to inform the arbiter as to which notifications the
   subscriber would like to receive.

   A subscription request can be thought of as a persistent search
   filter on the set of notifications that the subscription arbiter is
   aware of. Whenever the subscription arbiter receives a notification
   that matches the search filter it will forward the notification to
   the subscriber.

   This document defines a very basic search filter that allows a
   subscribing resource to specify a particular resource and a type of
   notification the subscribing resource is interested in. Whenever a
   notification of the specified type is made by the specified resource
   the subscription arbiter will forward the notification to the

4  Subscription Arbiters and Forwarded Notifications

   When forwarding a notification the subscription arbiter will change
   the Request-URI and the Host header value to match the subscriber
   who is to be notified. Subscription arbiters MUST NOT make any other
   changes to be made to the message unless the definition of the
   header or body element specifically provides for such alteration
   and/or for security reasons.

Cohen et al.                                                  [Page 4]

INTERNET-DRAFT               GENA Client                June 24, 1999


   The NOTIFY method is used to transmit a notification. The Request-
   URI of the notification method is the notifying resource's
   subscription arbiter who will handle forwarding the message to
   interested subscribers.

   The NOTIFY method may be sent using httpu or httpmu as specified in
   [HTTPUDP]. In the case of httpmu the multicast channel itself is
   treated as the subscription arbiter. NOTIFY methods sent using
   httpmu do not have responses.

   The NOTIFY method MUST contain a NT header and MAY contain a body, a
   NTS header and SID. The NT header of a NOTIFY request MUST NOT
   contain more than one URI. Subscribers MAY ignore the body in a
   subscription request. Subscription arbiters MAY remove and/or alter
   the value of the SID header in order to set it to the value that
   their subscriber is expecting. Note that in general notifying
   resources will not put SID headers on their notifications. This is
   generally a value that subscription arbiters add.

   Note that notifications to implied subscribers may not necessarily
   have SIDs. The client can tell the subscription arbiter to stop
   sending the notification by returning a 412 (Precondition Failed).

   A subscription arbiter which sends a NOTIFY method to a subscriber
   and gets back a 404 (Not Found) or 410 (Gone) MAY end the
   subscription. The subscription arbiter is not required to remember
   all the values in the callback header using in the SUBSCRIPTION
   request and so is not required to fallback to one of the values
   listed there in the case the current one fails. However, nothing
   prevents a subscription arbiter from providing this service.

5.1 Response Codes

   200 (OK) - This is the standard response to a NOTIFY received by a

   202 (Accepted) - This is the standard response to a NOTIFY received
   by a subscription arbiter.

   412 (Precondition Failed) - The client doesn't recognize the SID or
   the request doesn't have a SID and the client doesn't want to
   receive the notification.

5.2 Examples

5.2.1     TCP/IP

   NOTIFY /foo/bar HTTP/1.1
   Host: blah:923
   NT: ixl:pop

Cohen et al.                                                  [Page 5]

INTERNET-DRAFT               GENA Client                June 24, 1999

   NTS: clock:bark
   Timeout: Second-10003
   SID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6

   HTTP/1.1 200 O.K.

   A notification of type ixl:pop sub-type clock:bark has been sent out
   in response to the specified subscription. The request-URI could
   either identify a particular resource who is to be notified or a
   subscription arbiter who will then take responsibility for
   forwarding the notification to the appropriate subscribers.

5.2.2     Multicast UDP

   NOTIFY * HTTP/1.1
   Host: somemulticastIPaddress:923
   Timeout: Second-159
   NT: ixl:pop
   NTS: clock:bark

   As in the previous example this is a notification of type ixl:pop
   sub-type clock:bark but it has been sent out to the multicast
   channel as an unsolicited notification. Hence it does not have a SID
   header. Also, because it was sent out to a multicast UDP channel it
   also doesnÆt have a response.


   The SUBSCRIBE method is used to provide a subscription arbiter with
   a search filter to be used in determining what notifications to
   forward to the subscriber.

   The Request-URI of the SUBSCRIBE method specifies the subscription
   arbiter which will handle the subscription.

   A SUBSCRIBE request MUST have a NT header unless it is a re-
   subscription request. The NT header specifies what sort of
   notification the subscriber wishes to be notified of.

   A SUBSCRIBE request MUST have a Callback header unless it is a re-
   subscription request. The Callback header specifies how the
   subscriber is to be contacted in order to deliver the notification.

   A NTS header on a SUBSCRIBE method MUST be ignored. The base
   subscription search filter only supports filtering on the NT value
   of a notification. This limitation is meant to keep the subscription
   functionality at the minimum useful level. It is expected that
   future specifications will provide for more flexible subscription
   search filters.

Cohen et al.                                                  [Page 6]

INTERNET-DRAFT               GENA Client                June 24, 1999

   A SUBSCRIBE method MUST have a scope header unless it is a re-
   subscription request. The scope header identifies the resource that
   the subscriber wishes to receive notifications about.

   The Timeout request header, whose syntax is defined in section 9.8
   of [RFC2518] MAY be used on a SUBSCRIBE request. The header is used
   to request that a subscription live for the specified period of time
   before having to be renewed. Subscription arbiters are free to
   ignore this header.

   A subscription arbiter MUST ignore the body of a SUBSCRIBE request
   if it does not understand that body.

   If a subscription is successful then the subscription arbiter is
   responsible for returning notifications of the type specified in the
   NT header on the resource listed in the scope header.

   Notifications sent out as a result of a subscription MUST include a
   SID header set to the identifier of the subscription that cause the
   notification to be sent as well as a Timeout header identifying when
   the subscription will expire.

   Subscription arbiters MUST support callback URLs of type http.

   A successful response to the SUBSCRIBE method over http MUST include
   a Timeout response header and a SID header.

6.1 Re-Subscribing

   When the period of time specified in the Timeout response header
   passes the subscription MAY expire. In order to keep the
   subscription alive the subscriber MUST issue a SUBSCRIBE method with
   a SID header set to the subscription to be re-subscribed. A re-
   subscribe request MUST NOT have a NT header but it MAY have a
   Timeout and/or a Callback header.

   Note that the value in the Timeout response header will not take
   into account the time needed from when the value was generated until
   it was passed through the arbiter, put on the wire, sent to the
   subscriber, parsed by the subscriberÆs system and finally passed to
   the subscriberÆs program. Hence the value should be taken as an
   absolute upper bound. Subscribers are encouraged to re-subscribe a
   good period of time before the actual expiration of the

6.2 Response Codes

   200 (OK) - The subscription request has been successfully processed
   and a subscription ID assigned.

   400 Bad Request - A required header is missing.

Cohen et al.                                                  [Page 7]

INTERNET-DRAFT               GENA Client                June 24, 1999

   412 Precondition Failed - Either the subscription arbiter doesn't
   support any of the Callbacks, doesn't support one or more of the NTs
   or doesn't support one or more of the scopes.

6.3 Examples

6.3.1     Subscription

   SUBSCRIBE dude HTTP/1.1
   Host: iamthedude:203
   NT: ixl:pop
   Callback: <http://blah/bar:923>
   Scope: http://icky/pop
   Timeout: Infinite

   HTTP/1.1 200 O.K.
   Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6
   Timeout: Second-604800

   This subscription request asks the subscription arbiter
   http://iamthedude/dude:203 for a subscription on notifications of
   type ixl:pop from the resource http://icky/pop.

6.3.2     Re-Subscription

   SUBSCRIBE dude HTTP/1.1
   Host: iamthedude:203
   Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6
   Timeout: Infinite

   HTTP/1.1 200 O.K.
   Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6
   Timeout: Second-604800

   The subscription has been successfully renewed.

   The UNSUBSCRIBE method is used to terminate a subscription. The
   UNSUBSCRIBE method MUST include a SID header with the value of the
   subscription to be un-subscribed.

   If the SID identifies a subscription that the subscription arbiter
   does not recognize or knows is already expired then the arbiter MUST
   respond with a 200 (OK).

7.1 Example

   Host: iamtheproxy:203
   SID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6

Cohen et al.                                                  [Page 8]

INTERNET-DRAFT               GENA Client                June 24, 1999

   HTTP/1.1 200 O.k.

8  New HTTP Headers

8.1 NT Header

   The NT header is used to indicate the notification type.

   NT = "NT" ":" absoluteURI ; See section 3 of [RFC2396]

8.2 NTS Response Header

   The NTS response header is used to indicate the notification sub-
   type of a notification.

   NTS = "NTS" ":" absoluteURI

8.3 Callback Header

   The Callback header specifies, in order of preference, the means the
   subscriber would like the subscription arbiter to use to deliver

   Callback = "Callback" ":" *Coded-URI; See section 9.4 of [RFC2518]

8.4 Timeout Response Header

   The Timeout response header has the same syntax as the Timeout
   request header defined in section 9.8 of [RFC2518]. The subscription
   arbiter informs the subscriber how long the subscription arbiter
   will keep their subscription active without a re-subscribe using the
   Timeout response header.

8.5 SID Header

   The SID header contains a subscription ID.

   SID = "SID" ":" absoluteURI

8.6 Scope Request Header

   The scope request header indicates the resources the subscriber
   wishes to receive notifications about.

   SCOPE = "Scope" ":" absoluteURI

9  Future Work

   This specification defines a minimally useful set of notification
   functionality. It does not, however, address three critical issues
   that are needed by some notification environments. It is expected

Cohen et al.                                                  [Page 9]

INTERNET-DRAFT               GENA Client                June 24, 1999

   that all of these features can be provided in extension
   specifications to this base specification.

   The first issue is polling. In some environments, especially those
   with intermittent connectivity, it would be desirable for
   subscription arbiters to be able to pool up notifications and then
   to deliver them when the subscriber asks for them.

   The second issue is subscription arbiter to subscription arbiter
   communication. It is likely that subscription arbiters will want to
   communicate directly with each other in order to efficiently
   distribute notifications and subscriptions. This requires provision
   for notification routing and loop prevention.

   The third issue is support for depth functionality. In some systems
   one wishes to receive a notification about a resource and any of its
   children as the term is defined in [RFC2518].

10 Security Considerations


   The really horrible security concerns don't start until you build
   the subscription arbiter to arbiter protocol. Otherwise the arbiter
   is very close to a proxy in that it takes confidential information
   from a subscriber and/or notifying resource and is expected to do
   the right thing (TM) with it. Authentication and such prevents bogus
   notifications and subscriptions.]

11 IANA Considerations


12 Copyright

   The following copyright notice is copied from RFC 2026 [Bradner,
   1996], Section 10.4, and describes the applicable copyright for this

   Copyright (C) The Internet Society February 10, 1998. All Rights

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of

Cohen et al.                                                 [Page 10]

INTERNET-DRAFT               GENA Client                June 24, 1999

   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

13 Intellectual Property

   The following notice is copied from RFC 2026 [Bradner, 1996],
   Section 10.4, and describes the position of the IETF concerning
   intellectual property claims made against this document.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

14 References

   [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. Carter, and D.
   Jensen. HTTP Extensions for Distributed Authoring û WEBDAV. RFC
   2518, February 1999.

   [Bradner, 1996] S. Bradner, "The Internet Standards Process -
   Revision 3."  RFC 2026, BCP 9. Harvard University. October, 1996.

Cohen et al.                                                 [Page 11]

INTERNET-DRAFT               GENA Client                June 24, 1999

   [HTTPUDP] Y. Y. Goland. Multicast and Unicast UDP HTTP Requests.
   Internet Draft - a work in progress, draft-goland-http-udp-00.txt.

   [RFC2396] T. Berners-Lee, R. Fielding and L. Masinter.  Uniform
   Resource Identifiers (URI): Generic Syntax.  RFC 2396, August 1998.

15 Authors' Addresses

   Josh Cohen, Sonu Aggarwal, Yaron Y. Goland
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

   Email: {joshco,sonuag,yarong}

Cohen et al.                                                 [Page 12]