idnits 2.17.1 draft-cohen-gena-p-base-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 12) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9 Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10 IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 43 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([Bradner,1996]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 23, 1998) is 9499 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) -- Missing reference section? 'Bradner' on line 770 looks like a reference -- Missing reference section? '1996' on line 770 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT J. Cohen, Microsoft 3 4 Expires July, 1998 April 23, 1998 6 General Event Notification Architecture Base 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are 11 working documents of the Internet Engineering Task Force 12 (IETF), its areas, and its working groups. Note that other 13 groups may also distribute working documents as Internet- 14 Drafts. 16 Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or made obsolete 18 by other documents at any time. It is inappropriate to use 19 Internet-Drafts as reference material or to cite them 20 other than as "work in progress". 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Distribution of this document is unlimited. Please send 30 comments to the HTTP working group at . Discussions of the working group 32 are archived at 33 . 35 Abstract 36 At an ever increasing rate, new protocols are being 37 designed which achieve their desired functionality by 38 building upon HTTP. Many of them make good use of the 39 functionality and flexibility of the HTTP model, however, 40 a theme that is becoming common is the cry for a common 41 event notification architecture. 43 This specification defines a simple notification 44 architecture for URI addressable resources. URI 45 addressable resources can include, but are not limited to, 46 simple resources, html files, resources, URI addressable 47 objects, URI addressable process jobs or URI addressable 48 print jobs. 50 STATUS OF THIS MEMO...................................................1 51 ABSTRACT..............................................................1 52 1 DEFINITIONS ........................................................4 54 1.1 Subscription ....................................................4 55 1.2 Subscriber ......................................................4 56 1.3 Subscribed Resource .............................................4 57 1.4 Event ...........................................................4 58 1.5 Event Notification ..............................................4 59 2 MODEL ..............................................................4 60 2.1 Subscription Requests ...........................................5 61 2.1.1 Subscription-scheme: ..............................5 63 3 SUBSCRIPTION MESSAGES ..............................................5 64 3.1 New Methods .....................................................5 65 3.1.1 Subscription Methods ..............................5 66 3.1.2 Delivery Methods ..................................6 67 3.2 New Headers .....................................................6 68 3.2.1 Subscription-scheme: ..............................6 69 3.2.2 Delivery-scheme: ..................................6 71 3.2.3 Route-ID: .........................................6 73 3.2.4 Depth Header ......................................6 74 3.3 The URI scheme httpu: ...........................................7 75 4 RESPONSE CODES .....................................................7 76 4.1.1 241 Subscribed ....................................7 77 4.1.2 242 Subscription Failed ...........................7 78 4.1.3 243 Notification Failed ...........................7 79 4.1.4 244 Notification Acknowledged .....................7 81 4.1.5 245 Events Follow .................................7 82 4.1.6 246 No Events Pending .............................7 83 5 SCHEME DEFINITIONS .................................................7 84 5.1 Subscription Schemes ............................................7 85 5.2 Basic ...........................................................7 86 5.2.1 Trigger-condition .................................8 87 5.2.2 Subscription response parameters ..................8 89 5.3 Delivery Schemes ................................................9 90 5.4 Basic Delivery Scheme ...........................................9 91 5.4.1 Basic Delivery Scheme request parameters ..........9 92 5.4.2 Basic Delivery response parameters ...............10 93 6 COMPOUNDED SUBSCRIPTIONS ..........................................10 94 7 PROXY ROUTING .....................................................11 95 7.1 Example OPTIONS request ........................................11 96 7.2 Routing with a compliant Proxy .................................11 98 7.3 Routing with a non-compliant Proxy .............................11 99 8 EXAMPLES ..........................................................12 100 8.1 Method based Async HTTP Subscription ...........................12 101 8.1.1 Subscription request .............................12 102 8.1.2 Subscription response ............................12 103 8.1.3 Notification request .............................12 104 8.1.4 Notification response ............................12 106 8.2 Method based Polled Subscription ...............................12 107 8.2.1 Subscription request .............................13 108 8.2.2 Subscription response ............................13 109 8.2.3 Poll Request .....................................13 110 8.2.4 Poll response ....................................13 111 8.2.5 Poll Request .....................................13 112 8.2.6 Poll response ....................................13 113 8.3 Compounded Async UDP Subscription ..............................13 115 8.3.1 Subscription Request .............................13 116 8.3.2 Subscription Response ............................14 117 8.3.3 Event Notification ...............................14 118 9 SECURITY CONSIDERATIONS ...........................................14 119 10 IANA CONSIDERATIONS .............................................14 120 11 COPYRIGHT .......................................................14 121 12 INTELLECTUAL PROPERTY ...........................................15 123 13 REFERENCES ......................................................16 124 13.1 [Bradner, 1996] ................................................16 125 13.2 [Fielding et al., 1997] ........................................16 126 14 AUTHORS' ADDRESSES ..............................................16 128 Introduction 130 By using this protocol, a subscriber can establish a 131 subscription relationship with a resource and be notified 132 when a specified event occurs on that resource. Both 133 asynchronously delivered as well as polled delivery are 134 supported. 136 In addition to the general architecture and model 137 specified, this document defines a subscription scheme and 138 delivery scheme "basic" which provides a simple interface 139 to the mechanism. It is expected that additional, more 140 flexible and more complex schemes will be defined in the 141 future. 143 The protocol definition provides two main layers. The 144 first layer is a subscription protocol which is negotiated 145 over HTTP. This provides semantics and syntax for 146 establishing a relationship between a resource and a 147 subscriber which allows the subscriber to receive 148 notifications of changes or events on that resource. 150 The second layer is the definition of the syntax and 151 semantics of the actual notification delivery mechanisms. 152 Two main classes of delivery mechanisms are defined. 153 Asynchronous notifications allow a subscription server to 154 send an event notification at any time, without 155 maintaining a persistent network connection or resource 156 with the subscriber. Polled notifications allow a 157 backward compatible, although less elegant, mechanism for 158 notification delivery across a deployed infrastructure of 159 proxy servers and firewalls. 161 While the asynchronous mechanism is truly a "push" 162 mechanism, polled mechanisms are "pull". Depending on the 163 resources in question, their rate of change, and the 164 infrastructure in between a resource and a subscriber, 165 either may be appropriate. 166 . 168 1 Definitions 170 1.1 Subscription 172 A subscription is an established relationship where a 173 subscriber is interested in events which happen to a 174 resource. 176 1.2 Subscriber 178 A subscriber is an entity which negotiates a subscription 179 relationship with a subscription server to receive 180 notifications about events which happen to a resource. 182 1.3 Subscribed Resource 184 A subscribed resource is a resource which is the subject 185 of a subscription. 187 1.4 Event 189 An event happens to a resource. The occurrence of an 190 event is potentially a trigger for an event notification. 192 1.5 Event Notification 193 An event notification is a message delivered to a 194 subscriber describing an event which has happened to a 195 subscribed resource. 197 2 Model 199 The general model of the architecture takes place as 200 follows: 201 A subscriber declares a subscription request over HTTP via 202 the SUBSCRIBE method. Along with the subscribe method, 203 the subscriber indicates parameters which define the 204 subscription semantics as well as the notification 205 delivery semantics 207 2.1 Subscription Requests 209 Subscription requests have two main parameters: 211 2.1.1 Subscription-scheme: 213 Subscription type specifies a subscription scheme as well 214 as scheme related parameters. 215 Required parameters for a given scheme are: 217 2.1.1.1 Trigger-condition 219 The trigger condition defines the actions which will cause 220 an event notification to be delivered to the subscriber. 221 Typical trigger-conditions are UPDATE, DELETE, COMPLETED. 222 Exact trigger conditions are defined by the subscription 223 type scheme. 225 2.1.1.2 Delivery Mechanism 227 The delivery mechanism specifies the requested mechanism 228 for event notification. Typical delivery mechanisms are 229 "poll" or "async" 231 3 Subscription Messages 233 Subscription messages are transmitted via HTTP messages. 234 Subscription messages contain a subscription method and a 235 subscription command in the form of an XML body. 237 3.1 New Methods 239 The following are defined for use in the general event 240 notification architecture. 242 3.1.1 Subscription Methods 244 3.1.1.1 SUBSCRIBE 246 The SUBSCRIBE method is used to begin a subscription to a 247 resource. The URI included with SUBSCRIBE indicates the 248 resource which is being subscribed to. 250 3.1.1.2 UNSUBSCRIBE 252 The UNSUBSCRIBE method is used to terminate a 253 subscription. The URI included with UNSUBSCRIBE indicates 254 the resource which is being unsubscribed. 256 UNSUBCRIBE requires the parameter subscription-ID: to 257 indicate which resource is to be unsubscribed from. Its 258 syntax is dependent on the scheme used. 260 3.1.2 Delivery Methods 262 3.1.2.1 NOTIFY 264 NOTIFY is used for asynchronous notification delivery. It 265 is the method used for a subscription server initiated 266 HTTP request message destined for the subscription client. 268 3.1.2.2 POLL 270 POLL is used to check a resource for pending events. 272 3.2 New Headers 274 3.2.1 Subscription-scheme: 276 Subscription-scheme indicates the type of subscription 277 that is requested. 278 Syntax: 280 "Subscription-scheme:" subscription-scheme ";" scheme- 281 options 283 3.2.2 Delivery-scheme: 285 Delivery-scheme: indicates the type or mechanism of 286 delivery preferred for event notification on the 287 subscription. 289 Syntax: 290 "Delivery-scheme:" delivery-scheme ";" scheme-options 292 3.2.3 Route-ID: 294 Route-ID: indicates a route identifier for the message. 295 Each proxy or gateway in the path should append a route-id 296 header to the subscription message. When adding a new 297 route-ID header, the proxy should use an integer greater 298 than the current highest in the rid field. 300 Syntax: 301 "Route-ID:" rid ";" route-options 302 rid := integer 303 route-options := "delivery-uri" "=" URI 305 3.2.4 Depth Header 306 Depth = "Depth" ":" ("0" | "1" | "infinity") 308 The Depth header is used with methods executed on 309 resources which could potentially have internal members to 310 indicate whether the method is to be applied only to the 311 resource (Depth = 0), to the resource and its immediate 312 children, (Depth = 1), or the resource and all its progeny 313 (Depth = infinity). 315 3.3 The URI scheme httpu: 317 The URI scheme udp: is defined to include a host and a 318 port to which a UDP datagram can be sent. It is 319 specified as a URI with scheme `httpu'. 321 When used with the notification system, the payload of the 322 UDP datagram is to be the same as the HTTP messages 323 defined here as well. 325 4 Response Codes 327 In addition to various HTTP messages, GENA messages are 328 also defined. These messages may be returned in the 329 normal HTTP way as response codes, or may be included in 330 the body via XML . 332 4.1.1 241 Subscribed 333 4.1.2 242 Subscription Failed 334 4.1.3 243 Notification Failed 335 4.1.4 244 Notification Acknowledged 336 4.1.5 245 Events Follow 337 4.1.6 246 No Events Pending 339 5 Scheme Definitions 341 5.1 Subscription Schemes 343 The currently defined schemes are: 344 Subscription-scheme := "Basic" | "XML" 345 Scheme-options := name "=" value [ , name "=" value ]# 346 Name := quoted-string 347 Value := quoted-string 349 Other future specs may define other subscription schemes 350 which are used with this protocol. 352 5.2 Basic 354 The basic subscription scheme is used for simple event 355 notification. 357 When using basic subscriptions: 359 Subscription-scheme := "Basic" 361 Valid request parameters for scheme-options are: 363 5.2.1 Trigger-condition 365 The trigger type indicates what events will trigger a 366 notification on this subscription. 367 Acceptable values for trigger-condition are: 369 5.2.1.1 "update" 371 Any event which changes the state of the subscribed 372 resource will cause an update notification to be sent. 373 5.2.1.2 "delete" 375 Any event which causes the resource to be deleted or be 376 made unavailable shall cause a "delete" notification to be 377 sent. 379 5.2.1.3 "Completion" 381 Any event on a resource which indicates completion. This 382 is appropriate for job submission objects, process 383 control, or batch environments. 385 5.2.1.4 "implicit" 387 Implicit trigger events are for use on compounded 388 subscriptions only. In this case, the method compounded 389 upon produces a response which defines the trigger- 390 condition. 392 5.2.1.5 Lifetime 394 Lifetime indicates the requested lifetime of a 395 subscription. A server may choose to honor the requested 396 lifetime or to adjust it in the response. No matter what 397 the lifetime setting is, a subsequent UNSUBSCRIBE may 398 terminate a subscription. 399 Lifetime is expressed in seconds 401 5.2.2 Subscription response parameters 403 In response to a subscription message, the subscription 404 server responds with the delivery-scheme: header as 405 included by the client, but possibly with adjusted values. 406 In addition, the server will include: 408 5.2.2.1 Subscription-ID: 410 The subscription ID is a unique identifier with references 411 the subscription itself. In addition to identifying the 412 subscription, it can also be used with a polled resource. 414 5.3 Delivery Schemes 416 This specification defines the "basic" delivery scheme. 417 When using the "basic" delivery mechanism, the delivery- 418 mechanism scheme is set to "basic" 420 5.4 Basic Delivery Scheme 422 Delivery-scheme := "Basic" | "XML" 423 Scheme-options := name "=" value [ , name "=" value ]# 424 Name := quoted-string 425 Value := quoted-string 427 5.4.1 Basic Delivery Scheme request parameters 428 5.4.1.1 Delivery-scheme: 430 5.4.1.1.1 Asynchronous 432 Asynchronous notification delivery implies that the 433 delivery can occur at any time, without specific action of 434 the subscriber. Delivery occurs as an HTTP message where 435 the subscribed resource owner initiates an HTTP request to 436 the subscriber. This behaves compliant to 13.2 where the 437 traditional roles of server and client are reversed. 439 When using the delivery type "async", the scheme is set to 440 "basic" and scheme options are: 442 "Delivery-type" 443 "delivery-type" "=" "async" 445 "call-back" 447 "call-back:" "=" URI 448 Call-back indicates the URI of the event notification 449 receiver. URIs can be any valid URI type. Such as: 451 http://foo:port/bar 453 Indicates an http transaction via NOTIFY is to be sent 454 upon event notification. 456 httpu://address:port/path 457 Indicates that a UDP datagram containing an HTTP request 458 with NOTIFY and appropriate subscription-scheme are to be 459 sent. 461 mailto:user@domain 463 Indicates that an email message containing the same HTTP 464 message with NOTIFY is to be sent as the body of an email 465 message. 467 5.4.1.1.2 Polled 469 Polled delivery indicates that the subscription client 470 will poll the resource at a specified interval agreed upon 471 by the server and the client. 473 When using polled delivery, the basic delivery scheme 474 includes the following scheme-options 476 "poll-interval" 478 "poll-interval" "=" seconds 480 Poll-interval indicates the requests poll interval between 481 POLL requests from a subscriber on a subscription. 483 5.4.2 Basic Delivery response parameters 485 In response to a subscription message, the subscription 486 server responds with the delivery-scheme: header as 487 included by the client, but possibly with adjusted values. 489 6 Compounded Subscriptions 491 Subscription requests can be compounded, or added to a 492 general HTTP request such as "GET". To accomplish this, 493 along with "GET" or any other method, the headers 494 following are required. 496 Subscription-scheme: 497 Delivery-scheme: 498 Cache-control: 500 Subscribers may also wish to include an appropriate header 501 to indicate the non-cacheability of this request. Users 502 of HTTP/1.0 proxies should include "pragma: no-cache" and 503 users of HTTP/1.1 should include an appropriate header 504 such as "cache-control: no-store". 506 Since no specific subscription method is used and no 507 specific subscription response code is present in a 508 response, subscription success can be verified if a 509 subscription-scheme header is returned with a 510 subscription-id parameter. 512 7 Proxy Routing 514 Often, a client may reach a resource via a proxy server. 515 In this case, with a standard proxy server, asynchronous 516 call-back addresses may not be visible to an external 517 server. Because of this, the Route-ID: header is 518 introduced. 520 Subscription clients should poll their proxy chain to 521 detect which version of HTTP that proxy supports. In 522 addition, they should poll for support of the `route-id' 523 extension. This polling should be done via OPTIONS. 525 7.1 Example OPTIONS request 526 The proxy is myproxy.my.com on port 8080 528 OPTIONS * HTTP/1.1 529 Host: myproxy.my.com:8080 530 Compliance: uri=http://ietf.org/http-ext/route-id 531 Compliance: uri=http://ietf.org/http/v11 533 A successful response: 534 HTTP/1.1 200 Ok 535 Compliance: uri=http://ietf.org/http-ext/route-id 536 Compliance: uri=http://ietf.org/http/v11 538 Lack of a successful response indicates non-compliance 539 with HTTP/1.1 and Route-ID extensions. 541 7.2 Routing with a compliant Proxy 543 Compliant proxy servers are expected to include a "Route- 544 ID" header as they forward subscription request messages. 545 As they include the route-id header, the rid parameter is 546 to be an integer greater than the highest rid parameter of 547 any other route-id header already in a message. This 548 allows a deterministic route list for the message transit. 550 Servers who send responses to messages which include 551 route-id headers are expected to consume the highest rid 552 parameter route-id header, strip it from the message and 553 use that address as the connection proxy for notification 554 delivery. 556 7.3 Routing with a non-compliant Proxy 557 Since no deterministic way exists to determine an 558 appropriate call-back path for notification delivery, 559 subscribers should NOT select asynchronous call-back as a 560 delivery type. 562 8 Examples 564 This section describes some examples using the 565 notification architecture. 567 8.1 Method based Async HTTP Subscription 569 Here, as subscriber subscribes to a resource 570 http://server/document.html. The delivery mechanism 571 requested is asynchronous with TCP based HTTP. The call- 572 back address is http://mypc:8080/ 574 8.1.1 Subscription request 576 SUBSCRIBE http://server/document.html HTTP/1.1 577 Host: server 578 Subscription-scheme: basic ; trigger-condition="update" 579 Delivery-scheme: basic ; delivery-type="async" ,call- 580 back=http://mypc:8080/ 582 8.1.2 Subscription response 584 HTTP/1.1 241 Subscribed 585 Server: foo 586 Subscription-scheme: basic ; subscription-id="1049" 587 ,trigger-condition="update" 588 Delivery-scheme: basic ; delivery-type="async" ,call- 589 back=http://mypc:8080/ 591 8.1.3 Notification request 593 NOTIFY http://mypc:8080/ HTTP/1.1 594 Host: server 595 Subscription-scheme: basic ; subscription-id="1049" 597 8.1.4 Notification response 599 HTTP/1.1 244 Notification Acknowledged 600 Server: mypc-server 601 Date: [date] 603 8.2 Method based Polled Subscription 604 A subscriber subscribes to http://server/document.html 605 with polled delivery. The server overrides the requested 606 poll-interval. 608 8.2.1 Subscription request 610 SUBSCRIBE http://server/document.html HTTP/1.1 611 Host: server 612 Subscription-scheme: basic ; trigger-condition="update" 613 Delivery-scheme: basic ; delivery-type="poll" , poll- 614 interval="10" 616 8.2.2 Subscription response 618 HTTP/1.1 241 Subscribed 619 Server: foo 620 Subscription-scheme: basic ; subscription-id="1049" 621 ,trigger-condition="update" 622 Delivery-scheme: basic ; delivery-type="poll", poll-interval="30" 624 8.2.3 Poll Request 626 POLL http://server/document.html HTTP/1.1 627 Host: server 628 Subscription-scheme: basic ; subscription-id="1049" 630 8.2.4 Poll response 632 HTTP/1.1 246 No events pending 633 Server: mypc-server 634 Date: [date] 636 8.2.5 Poll Request 638 POLL http://server/document.html HTTP/1.1 639 Host: server 640 Subscription-scheme: basic ; subscription-id="1049" 642 8.2.6 Poll response 644 HTTP/1.1 245 Events Pending 645 Server: mypc-server 646 Date: [date] 647 Subscription-scheme: basic ; subscription-id="1049" 648 ,trigger-condition="update" 650 8.3 Compounded Async UDP Subscription 652 A subscriber requests a subscription on a resource 653 http://www.foo.bar/files/ the subscription is on the 654 children of the collection, not the resource itself. The 655 subscription is compounded on a GET. 657 8.3.1 Subscription Request 658 GET /files/ HTTP/1.1 659 Host: www.foo.bar 660 Depth: 1 661 Subscription-scheme: basic ; trigger-condition="implicit" 662 Delivery-scheme: basic ; delivery-type="async", call- 663 back="httpu://mypc:8080/app" 664 Content-type: text/xml 665 Content-Length: xyz 667 8.3.2 Subscription Response 669 HTTP/1.1 200 OK 670 Subscription-scheme: basic ; subscription-id="1049" 671 ,trigger-condition="implicit" 672 Delivery-scheme: basic ; delivery-type="async" ,call- 673 back=http://mypc:8080/app 674 Content-Type: text/html 675 Content-Length: xxxxx 677 8.3.3 Event Notification 679 Event notification in this case is the server sending a 680 UDP datagram to mypc on port 8000. Note that there is no 681 acknowledgement in this case. 683 [ UDP datagram to host mypc on port 8000 ] 684 [payload contents: ] 685 NOTIFY http://mypc:8080/app HTTP/1.1 686 Subscription-scheme: basic ; subscription-id="1049" 688 9 Security Considerations 690 Servers responding to subscription requests should be 691 careful to implement a rational security policy for 692 subscriptions which protects the event notification data 693 about resources as well as the resources themselves. 694 Allowing a subscriber to receive notifications on a 695 resource which that subscriber would not normally have 696 access to may unknowingly reveal information about that 697 resource or the contents itself. 699 10 IANA Considerations 701 This document introduces no new IANA considerations. 703 11 Copyright 704 The following copyright notice is copied from RFC 2026 705 [Bradner, 1996], Section 10.4, and describes the 706 applicable copyright for this document. 708 Copyright (C) The Internet Society February 10, 1998. All 709 Rights Reserved. 711 This document and translations of it may be copied and 712 furnished to others, and derivative works that comment on 713 or otherwise explain it or assist in its implementation 714 may be prepared, copied, published and distributed, in 715 whole or in part, without restriction of any kind, 716 provided that the above copyright notice and this 717 paragraph are included on all such copies and derivative 718 works. However, this document itself may not be modified 719 in any way, such as by removing the copyright notice or 720 references to the Internet Society or other Internet 721 organizations, except as needed for the purpose of 722 developing Internet standards in which case the procedures 723 for copyrights defined in the Internet Standards process 724 must be followed, or as required to translate it into 725 languages other than English. 727 The limited permissions granted above are perpetual and 728 will not be revoked by the Internet Society or its 729 successors or assignees. 731 This document and the information contained herein is 732 provided on an "AS IS" basis and THE INTERNET SOCIETY AND 733 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 734 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 735 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 736 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 737 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 739 12 Intellectual Property 741 The following notice is copied from RFC 2026 [Bradner, 742 1996], Section 10.4, and describes the position of the 743 IETF concerning intellectual property claims made against 744 this document. 746 The IETF takes no position regarding the validity or scope 747 of any intellectual property or other rights that might be 748 claimed to pertain to the implementation or use other 749 technology described in this document or the extent to 750 which any license under such rights might or might not be 751 available; neither does it represent that it has made any 752 effort to identify any such rights. Information on the 753 IETF's procedures with respect to rights in standards- 754 track and standards-related documentation can be found in 755 BCP-11. Copies of claims of rights made available for 756 publication and any assurances of licenses to be made 757 available, or the result of an attempt made to obtain a 758 general license or permission for the use of such 759 proprietary rights by implementers or users of this 760 specification can be obtained from the IETF Secretariat. 762 The IETF invites any interested party to bring to its 763 attention any copyrights, patents or patent applications, 764 or other proprietary rights which may cover technology 765 that may be required to practice this standard. Please 766 address the information to the IETF Executive Director. 768 13 References 770 13.1 [Bradner, 1996] 771 S. Bradner, "The Internet Standards Process - Revision 772 3." RFC 2026, BCP 9. Harvard University. October, 1996. 774 13.2 [Fielding et al., 1997] 775 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 776 Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068. 777 U.C. Irvine, DEC, MIT/LCS. January, 1997. 779 14 Authors' Addresses 781 Josh Cohen 782 Microsoft Corporation 783 One Microsoft Way 784 Redmond, WA 98052-6399 786 Email: