INTERNET DRAFT J. Cohen, Microsoft S. Aggarwal, Microsoft Y. Y. Goland, Microsoft Expires April, 2000 September 6, 2000 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. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Please send comments to the SSDP mailing list. Subscription information for the SSDP mailing list is available at http://www.upnp.org/resources/ssdpmail.htm. Abstract 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 Cohen et al. [Page 1] INTERNET-DRAFT GENA Base September 6, 2000 arbiters. These arbiters, called subscription arbiters, are able to form, through an unspecified mechanism, relationships with other subscription arbiters in order to distribute notifications. 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 Changes 2.1 Since V00 [Ed. Note: Aren’t there times when the service needs to hear the subscriptions? When the identity of the subscriber will effect the output? Of course… Notification identifiers must be explicit in the notification, not implicit as a function of the address.] [Ed. Note: We need to look into adding support for sequence numbers on events, this is needed for things like UPnP. If this doesn't end up effecting how the arbiter works then we should put it into a separate draft.] [Talk about the scope header having values other than the URL of the resource, we are using the UPnP example where you would put the USN value into the scope. Everyone needs to pay attention to the scope header!!!!] [Add a note that if no Scope header is included then the default is to treat the Request-URI as the scope.] [What do you do if someone subscribes to something they are already subscribed to? The question is tricky because, short of using authentication, you don’t know who “someone” is and even then, because multiple programs may be running, you can’t be sure if you are really talking to the same person. My instinct would be to just give them a second parallel subscription.] [Think REALLY hard about allowing for multiple values in a NT header] 3 Definitions 3.1 Event Any occurrence that may potentially trigger a notification. 3.2 Subscription An established relationship in which a resource has indicated interest in receiving certain notifications. 3.3 Subscriber A resource that negotiates a subscription with a subscription arbiter. Cohen et al. [Page 2] INTERNET-DRAFT GENA Base September 6, 2000 3.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. 3.5 Notifying Resource A resource that issues notifications, for example, a subscription arbiter. 3.6 Subscription Arbiter A resource that accepts subscriptions, receives notifications and forwards those notifications to its subscribers. 3.7 Notification A message sent by a notifying resource to provide notification of an event. 3.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. 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. 3.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. 3.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. 3.11 Scope Scopes are used in a subscription to indicate the notifying resource the subscriber is interested in. Cohen et al. [Page 3] INTERNET-DRAFT GENA Base September 6, 2000 4 Notification Model [Ed. Note: Aren’t there times when the service needs to hear the subscriptions? When the identity of the subscriber will effect the output? Of course… Notification identifiers must be explicit in the notification, not implicit as a function of the address.] [Ed. Note: We need to look into adding support for sequence numbers on events, this is needed for things like UPnP. If this doesn't end up effecting how the arbiter works then we should put it into a separate draft.] 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 specification. 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 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. 4.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. Cohen et al. [Page 4] INTERNET-DRAFT GENA Base September 6, 2000 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. 4.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 subscriber. 5 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. 6 Stuff In the case where a subscriber sends a subscription request to an arbiter: Is it OK if the arbiter rejects subscription requests that don't match certain notification type criteria? or should the arbiter be totally unaware of any notification types at this point? In the case where a notifying resource sends a notify request to an arbiter: Is it OK if the arbiter rejects notification requests that don't match certain notification type criteria? or should the arbiter just accept the notification request and filter the available subscriptions taking the notification type as criteria? In the hypothetical case where the arbiter just accepted subscriptions of certain types, could an arbiter just be dedicated to one subscription type? If the previous statement was affirmative then the existence of a notification type for that particular arbiter wouldn't even make sense right? We need to discuss the implicit relationship between an arbiter and its subscribers, all the unstated assumptions. Cohen et al. [Page 5] INTERNET-DRAFT GENA Base September 6, 2000 The subscription server may not necessarily have been the one who created a SID, it could have been the service who is using the subscription server to do replication. In that case a subscription request could come in with a SID on it, a ref-counted SID. But this bug me because a SID indicates a relationship. How does one change one’s call back for a SID? Especially if you want to send in the change command from somewhere other than the place receiving the notification so you can’t just check the address on the packet. Do we need tow types of SIDs? I don’t just want to overload NT. I think NT and NTS should be left alone to just give notification type. They shouldn’t be overloaded to also provide functional information… functional is the wrong word. They shouldn’t be overloaded to provide routing information. Event type. Event Sub-type. Event group (if any). Individual subscription. The problem is that the last two are not always both necessary. For example, an individual subscription ID is not necessary if the events are only sent to a multicast group. Additionally the event group ID isn’t necessary if the event only goes to a single end point. Maybe we need an end point identifier? We need a way to say “Stop sending the events to this call-back, send it to this other call-back.” THIS ISN’T GOOD ENOUGH. What if two programs are both at the same call- back? You need ref counting. I guess what I’m trying to avoid is implicit ref-counting, I would rather have explicit ref-counting. That is, I would like the ref count to be included in each request in the person of an ID that is unique to every listener, this is independent of call-back address. Make sure that if you leave off the NT then this means you want to receive all notifications from the identified scope. Also make sure that we can use scope as a selector for video streams on a video server. We need to add a “connect and flood” mechanism such that if you connect to a certain TCP port you will get events. There is no subscribe/unsubscribe. We also need to discuss this feature for multicasting. If you cut the connection then you won’t get any more events. 7 NOTIFY HTTP Method 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 unreliable administrative scoped multicast UDP as specified in [HTTPMU]. In such a case the multicast Cohen et al. [Page 6] INTERNET-DRAFT GENA Base September 6, 2000 channel is treated as the subscription arbiter. When a NOTIFY is sent using multicast UDP as a transport there is no response. The NOTIFY method MUST contain a NT header and MAY contain a body, a NTS header and SID. 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). 7.1 Response Codes 200 (OK) - This is the standard response to a NOTIFY received by a subscriber. 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. 7.2 Examples 7.2.1 TCP/IP NOTIFY /foo/bar HTTP/1.1 Host: blah:923 NT: ixl:pop NTS: clock:bark 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. 7.2.2 Multicast UDP NOTIFY * HTTP/1.1 Host: somemulticastIPaddress:923 NT: ixl:pop NTS: clock:bark Cohen et al. [Page 7] INTERNET-DRAFT GENA Base September 6, 2000 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. 8 SUBSCRIBE HTTP Method [Talk about the scope header having values other than the URL of the resource, we are using the UPnP example where you would put the USN value into the scope. Everyone needs to pay attention to the scope header!!!!] 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 Call-Back header unless it is a re- subscription request. The Call-Back header specifies how the subscriber is to be contacted in order to deliver the notification. A SUBSCRIBE method MUST NOT have a NTS header. 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. 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 [WEBDAV] 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. A successful response to the SUBSCRIBE method MUST include a Timeout response header and a SUBID header. Cohen et al. [Page 8] INTERNET-DRAFT GENA Base September 6, 2000 [Add a note that if no Scope header is included then the default is to treat the Request-URI as the scope.] [What do you do if someone subscribes to something they are already subscribed to? The question is tricky because, short of using authentication, you don’t know who “someone” is and even then, because multiple programs may be running, you can’t be sure if you are really talking to the same person. My instinct would be to just give them a second parallel subscription.] 8.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 Call-Back 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 subscription. 8.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. 412 Precondition Failed - Either the subscription arbiter doesn't support any of the call-backs, doesn't support the NT or doesn't support the scope. This code is also used on resubscription requests to indicate that the subscription no longer exists. 8.3 Examples 8.3.1 Subscription SUBSCRIBE dude HTTP/1.1 Host: iamthedude:203 NT: ixl:pop Call-Back: Scope: http://icky/pop Timeout: Infinite HTTP/1.1 200 O.K. Subscription-ID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6 Timeout: Second-604800 Cohen et al. [Page 9] INTERNET-DRAFT GENA Base September 6, 2000 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. 8.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. 9 UNSUBSCRIBE HTTP Method 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). 9.1 Response Codes 200 (OK) - Unsubscribe succeeded. 412 (Precondition Failed) – The SID was not recognized. 9.2 Example UNSUBSCRIBE dude HTTP/1.1 Host: iamtheproxy:203 SID: uuid:kj9d4fae-7dec-11d0-a765-00a0c91e6bf6 HTTP/1.1 200 O.k. 10 New HTTP Headers 10.1 NT Header [Think REALLY hard about allowing for multiple values in a NT header] The NT header is used to indicate the notification type. NT = "NT" ":" absoluteURI ; See section 3 of [RFC2396] Cohen et al. [Page 10] INTERNET-DRAFT GENA Base September 6, 2000 10.2 NTS Response Header The NTS response header is used to indicate the notification sub-type of a notification. NTS = "NTS" ":" absoluteURI 10.3 Call-Back Header The Call-Back header specifies, in order of preference, the means the subscriber would like the subscription arbiter to use to deliver notifications. Call-Back = "Call-Back" ":" *Coded-URI; See section 9.4 of [WEBDAV] 10.4 Timeout Response Header The Timeout response header has the same syntax as the Timeout request header defined in section 9.8 of [WEBDAV]. 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. 10.5 SID Header The SID header contains a subscription ID. SID = "SID" ":" absoluteURI 10.6 Scope Request Header The scope request header indicates the resource the subscriber wishes to receive notifications about. SCOPE = "Scope" ":" absoluteURI 11 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 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 Cohen et al. [Page 11] INTERNET-DRAFT GENA Base September 6, 2000 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 [WEBDAV]. 12 Security Considerations TBD. [Notes: 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. Another problem is if someone sends in a subscription request with the call-back pointing at someone else. This could be used for a denial of service attack. Arbiters should authenticate subscribers and probably the call-back points as well.] 13 Acknowledgements Jesus Ruiz-Scougall (Exchange) Erik Christensen (VB) (Exchange) Ting Cai 14 IANA Considerations None. 15 Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society February 10, 1998. All Rights Reserved. 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 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 English. Cohen et al. [Page 12] INTERNET-DRAFT GENA Base September 6, 2000 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 16 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 Director. 17 References [WEBDAV] [Bradner, 1996] S. Bradner, "The Internet Standards Process - Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996. [HTTPMU] [HTTP11] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. Internet Draft – Work in Progress. http://www.ietf.org/internet- drafts/draft-ietf-http-v11-spec-rev-06.txt, November 18, 1998. [RFC2396] http://www.rfc-editor.org/rfc/rfc2396.txt Cohen et al. [Page 13] INTERNET-DRAFT GENA Base September 6, 2000 18 Authors' Addresses Josh Cohen, Sonu Aggarwal, Yaron Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: {joshco,sonuag,yarong}@microsoft.com Cohen et al. [Page 14]