idnits 2.17.1 draft-livingood-web-notification-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 11, 2010) is 5189 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2434' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'RFC2915' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 744, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 4329 (Obsoleted by RFC 9239) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Chung 3 Internet-Draft A. Kasyanov 4 Intended status: Informational J. Livingood 5 Expires: August 15, 2010 N. Mody 6 B. Van Lieu 7 Comcast 8 February 11, 2010 10 Example of an ISP Web Notification System 11 draft-livingood-web-notification-01 13 Abstract 15 The objective of this document is to describe one method of providing 16 notifications to web browsers that has been deployed by Comcast, a 17 large Internet Service Provider (ISP). Such a notification system 18 can be used by an ISP to provide near-immediate notifications to 19 their users, such as to warn them that their traffic exhibits 20 patterns that are indicative of malware or virus infection, for 21 example. There are many proprietary systems that can perform such 22 notifications on the market today, some of which use inline-based 23 Deep Packet Inspection (DPI) systems. This document describes one 24 example of such a system that does not rely upon DPI systems, and is 25 instead based in open standards and open source systems. While the 26 system described herein is in some ways specific to the Data-Over- 27 Cable Service Interface Specifications (DOCSIS) networks used by most 28 cable-based broadband ISPs, components and concepts described in this 29 document can generally be applied to many different types of 30 networks. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on August 15, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 85 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. High-Level Design of the System . . . . . . . . . . . . . . . 4 87 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 5 88 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 4.2. Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . 6 90 4.3. ICAP Server . . . . . . . . . . . . . . . . . . . . . . . 6 91 4.4. Messaging Service . . . . . . . . . . . . . . . . . . . . 7 92 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7 93 5.1. Functional Components Described . . . . . . . . . . . . . 7 94 5.2. Functional Diagram . . . . . . . . . . . . . . . . . . . . 9 95 6. High Level Communication Flow . . . . . . . . . . . . . . . . 10 96 7. Communication Between Web Proxy and ICAP Server . . . . . . . 11 97 8. End-to-End Web Notification Flow . . . . . . . . . . . . . . . 13 98 8.1. Step-by-Step Description of the End-to-End Web 99 Notification Flow . . . . . . . . . . . . . . . . . . . . 13 100 8.2. Diagram of the End-to-End Web Notification Flow . . . . . 14 101 9. Example HTTP Headers for a Web Notification . . . . . . . . . 16 102 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 17 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 105 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 106 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 108 14.2. Informative References . . . . . . . . . . . . . . . . . . 19 109 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 20 110 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 113 1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Introduction 121 Internet Service Providers (ISPs) have a need for a system that is 122 capable of communicating with selected customers in a nearly 123 immediate manner. Given the prevalence of the web browser as the 124 predominant client software in use by Internet users, the web browser 125 is an ideal vehicle for providing notifications. This document 126 describes a system that has been deployed by Comcast, a large 127 broadband ISP, to provide notifications to web browsers, which can be 128 used to provide such near-immediate notifications to users. This 129 type of system is designed to provide a non-intrusive, though 130 obvious, notification to a user's web browser. 132 In evaluating potential solutions, most commercially available 133 systems were either proprietary and/or required inline-based Deep 134 Packet Inspection (DPI) systems. However, Comcast and many other 135 ISPs may desire to use a system based on open standards, non- 136 proprietary software, and which does not require the use of DPI. 137 While the system described herein is specific to the Data-Over-Cable 138 Service Interface Specifications (DOCSIS, [CableLabs DOCSIS]) 139 networks used by most cable-based broadband ISPs, components and 140 concepts described in this document can generally be applied to many 141 different types of networks. 143 3. High-Level Design of the System 145 The web notification system design is based on the use of the 146 Internet Content Adaptation Protocol [RFC3507]. The design uses open 147 source applications such as the Squid Web Proxy, the GreasySpoon ICAP 148 server, and Apache Tomcat. The ICAP protocol allows for message 149 transformation or adaptation. An ICAP client passes a HyperText 150 Transport Protocol (HTTP, [RFC2616]) message to an ICAP server for 151 some type of processing. The ICAP Server will in turn respond back 152 to the client with the modified HTTP message containing the 153 notification message. 155 Message modification itself may then be provided via either a HTTP 156 request or HTTP response. However, for the specific system described 157 in this document, only the HTTP response is modified, by using the 158 'respmod' method defined in Section 3.2 of [RFC3507]. 160 4. Design Requirements 162 This section describes all of the requirements taken into 163 consideration for the design of this system. 165 4.1. General 167 REQ1: TCP Port 80: The system should provide notifications via TCP 168 port 80, the well-known port for HTTP traffic. 170 REQ2: Whitelisting: It is possible that the HyperText Markup 171 Language (HTML, [RFC1866]) or JavaScript [RFC4329] used for 172 notifications may cause problems for access to a particular 173 website. Therefore, such a system should be capable of using 174 a whitelist of website Uniform Resource Indicators (URIs, 175 [RFC2396]) or Fully Qualified Domain Named (FQDNs, Section 176 5.1 of [RFC1035]) that conflict with the system, to instruct 177 the system to not provide a notifications related to certain 178 sites, in order to reduce any errors or unexpected results. 180 REQ3: Instant Messaging (IM): Some IM clients use TCP port 80 in 181 their communications, often as an alternate port when 182 standard, well-known ports do not work. This system should 183 not conflict with or cause unexpected results for IM clients. 185 REQ4: Handling of Active Sessions: To the extent that a web 186 notification system must temporarily route TCP port 80 187 traffic, in order to provide a notification, previously 188 active TCP port 80 sessions should be maintained. 190 REQ5: No TCP Resets: The use of TCP resets has been widely 191 criticized, both in the Internet community generally as well 192 as in [RFC3360]. As such, except for the case of 193 unintentional errors, the use of TCP resets must not be used. 195 REQ6: Non-Disruptive: The web notification system should not 196 disrupt the end user experience, such as causing significant 197 clients errors. 199 REQ7: Notification Acknowledgement: Once a user responds and 200 acknowledges a notification, the notification should 201 immediately stop, so it is not repeatedly and annoyingly 202 presented, again and again, in a short period of time. 204 REQ8: Non-Modification of Content: Such a system should not 205 significantly alter the content of any website the user is 206 accessing. 208 REQ9: Unexpected Content: The system should transparently handle 209 traffic for which it cannot provide a web notification. 210 Thus, widely varying content should be expected, and all such 211 unexpected traffic should be able to be handled by the system 212 without generating errors or unexpected results. 214 REQ10: No Caching: Web content must not be cached by the system. 216 REQ11: No Advertising Replacement or Insertion: The system must not 217 be used to replace any advertising provided by a website, or 218 insert advertising into websites where none was intended by 219 the owner of a given website. 221 4.2. Web Proxy 223 REQ12: Open-Source Software: The system should use an open source 224 web proxy server, such as Squid. (While it is possible to 225 use any web proxy, the use of open source, and openly 226 documented software is recommended.) 228 REQ13: ICAP Client: The web proxy server should have an integrated 229 ICAP client. 231 REQ14: Access Control: Access to the proxy should be limited 232 exclusively to the IP addresses of users for which 233 notifications are intended, and only for limited periods of 234 time. Furthermore, if a Session Management Broker (SMB) is 235 utilized, as described in Section 5.1 below, then the proxy 236 should restrict access only to the IP of the SMB. 238 4.3. ICAP Server 240 REQ15: Request and Response Support: The system should support both 241 request and response adaptation. 243 REQ16: Consistency: The system must be able to consistently provide 244 a specific notification. 246 REQ17: Multiple Notification Types: The system must be able to 247 provide many different types of notifications. 249 REQ18: Simultaneous Differing Notifications: The system must be able 250 to simultaneously serve multiple notifications, including 251 notifications of varying types, to different users. As a 252 result, User A should be able to get the notification 253 intended specifically for User A, at the same time that User 254 B receives an entirely different notification, which was 255 intended specifically for User B. 257 4.4. Messaging Service 259 REQ19: Messaging Service: The Messaging Service, as described in 260 Section 5.1 below caches the notifications for each specific 261 user. Thus, by caching the notification messages, the system 262 may provide notifications without significantly affecting the 263 web browsing experience of the user. 265 REQ20: Process Acknowledgements: The Messaging Service should 266 process acknowledgements to properly remove entries from the 267 cache and forward acknowledgements to the Messaging Service. 269 REQ21: Ensure Notification Targeting Accuracy: The Messaging Service 270 must ensure that notifications are presented to the intended 271 users. 273 REQ22: Keep Records for Customer Care: The Messaging Service should 274 maintain some type of record that a notification has been 275 presented and/or acknowledged, in case a user inquires with 276 customer care personnel. 278 5. Functional Overview 280 This section defines the various core functional components of the 281 system. These components are then shown in a diagram to describe how 282 the various components are linked and relate to one another. 284 5.1. Functional Components Described 286 It should be noted that when specific software cited is but one 287 example of a possible selection for each component. As the state of 288 the art changes, so too many the best or most appropriate software 289 choices here vary. 291 5.1.A. Web Proxy: A standard web proxy server. The initial version 292 of this system uses the Squid Proxy, an open source 293 application in wide use. 295 5.1.B. ICAP Server: This should be an open source application 296 capable of supporting content adaptation in both request and 297 response modes. The ICAP Server retrieves the notifications 298 from the Messaging service cache when content adaption is 299 needed. The initial version of this system uses GreasySpoon, 300 an open source application. 302 5.1.C. Customer Database: The Customer Database holds the user 303 information including the notifications setup for each user. 304 The database may also hold status of which users were 305 notified and users pending notification. 307 5.1.D. The Messaging Service is a process engine that retrieves 308 specific web notification messages from a catalog of possible 309 notifications. A When a notification for a specific user is 310 not in cache, the process retrieves this information from the 311 Customer Database and populates the cache for a specific 312 period of time. The initial version of this service uses 313 Apache Tomcat, an open source application. 315 5.1.E. Session Management Broker: A Load Balancer (LB) with a 316 customized layer 7 inspection policy was used to 317 differentiate between HTTP and non-HTTP traffic on TCP port 318 80. The LB functions as a full stateful TCP proxy with the 319 ability to forward packets from existing TCP sessions that do 320 not exist in the internal session table. New HTTP sessions 321 are load balanced to a proxy layer either transparently or 322 using source Network Address Translation (NAT [RFC1631]) from 323 the LB, with additional layer 7 inspection as needed. 324 Established TCP sessions not in the LB session table are 325 simply forwarded to the destination transparently via the 326 proxy layer. The initial version of this system uses a 327 Session Management Broker which has been developed internally 328 by Comcast. 330 5.2. Functional Diagram 332 +--------+ +------------+ +----------+ 333 | ICAP | <----> | Messaging | <----> | Customer | 334 | Server | | Service | | Database | 335 +--------+ +------------+ +----------+ 336 ^ 337 | +----------+ 338 | | | 339 | +-------> | Internet | <-------+ 340 | | | | | 341 | | +----------+ | 342 | | ^ | 343 | | | | 344 v v | | 345 +----------+ V v 346 |+--------+| +-------+ +--------+ 347 || ICAP || <----> | SMB | <---> | Access | 348 || Client || +-------+ | Router | 349 |+--------+| +--------+ 350 || SQUID || ^ 351 || Proxy || | 352 |+--------+| | 353 +----------+ | 354 v 355 +----------+ 356 | Network | 357 | Element* | 358 +----------+ 359 ^ 360 | 361 | 362 v 363 +------+ 364 | PC | 365 +------+ 367 * An access network element, such as a Cable Modem Termination 368 System (CMTS). 370 Figure 1: Web Notification System - Functional Components 372 6. High Level Communication Flow 374 6.A. Setup Differentiated Services (DiffServ): Using DiffServe 375 [RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260] 376 [RFC4594], set a policy to direct TCP port 80 traffic to the 377 web notification system's web proxy. 379 6.B. Session Management: TCP port 80 Packets are routed to a load 380 balancer where the load balancer then distinguishes new TCP 381 port 80 sessions as HTTP or non-HTTP. For HTTP sessions, the 382 load balancer forwards to the proxy. For non-HTTP traffic such 383 as instant messaging (IM), the load balancer either forwards to 384 a TCP proxy layer for handling or operates as a full TCP proxy 385 for non-HTTP sessions and forwards to the destination. Pre- 386 established TCP sessions on port 80 are identified by the load 387 balancer and forwarded with no impact. 389 6.C. Web Proxy Forwards Request: The web proxy forwards the HTTP 390 request on to the destination site, as a web proxy normally 391 would do. 393 6.D. On Response, Send Message to ICAP Server: When the HTTP 394 response is received, the web proxy sends a message to the ICAP 395 server for the web notification. 397 6.E. Messaging Service: Messaging Service should respond with 398 appropriate notification content or null response if 399 notification is not cached. 401 6.F. ICAP Server Responds: The ICAP server responds and furnishes 402 the appropriate content of the appropriate web notification to 403 the web proxy. 405 6.G. Web Proxy Sends Response: The web proxy then sends a "200 OK" 406 HTTP message to the original web client, containing the 407 originally requested content and the web notification. 409 6.H. User Response: The user observes the web notification, and 410 clicks an appropriate option, such as: OK/acknowledged, snooze/ 411 remind me later, etc. 413 6.I. More Information: Depending upon the notification, the user may 414 be provided with more information. Using the example of a web 415 notification to a user explaining that it is highly likely that 416 they have been infected with a virus or malware, the user may 417 click an acknowledgement that indicates that clicking that will 418 take them to a page with information about virus/malware 419 scanning and remediation. 421 6.J. Turn Down DiffServ: Once the notification transaction has 422 completed, remove any special DiffServ settings. 424 7. Communication Between Web Proxy and ICAP Server 425 +------------+ 426 | | 427 | www URL | 428 | | 429 +------------+ 430 ^ | 431 | | 432 (2)| |(3) 433 | | 434 | v 435 +--------+ (4) +--------+ (4) +--------+ 436 | |------------>| |------------>| | 437 | | | | | | 438 | | (5) | | (5) | | 439 | |<------------| |<------------| | 440 | Proxy | | ICAP | | ICAP | 441 | Module | (6) | Client | (6) | Server | 442 | |------------>| |------------>| | 443 | | | | | | 444 | | (7) | | (7) | | 445 | |<------------| |<------------| | 446 +--------+ +--------+ +--------+ 447 ^ | 448 | | 449 (1)| |(8) 450 | | 451 | v 452 +------------+ (9) +------------+ 453 | |----------------------------->| | 454 | | | | 455 | Browser | | Web Server | 456 | | (10) | | 457 | |<-----------------------------| | 458 +------------+ +------------+ 460 (1) - HTTP GET (TCP 80) 461 (2) - Proxy HTTP GET (TCP 80) 462 (3) - HTTP 200 OK w/ Response 463 (4) - ICAP RESPMOD 464 (5) - ICAP 200 OK 465 (6) - TCP Stream - Encapsulate Header 466 (7) - ICAP 200 OK Insert Message 467 (8) - HTTP 200 OK w/ Response + Message Frame 468 (9) - HTTP GET for Message 469 (10) - HTTP 200 w/ Message Content 470 Figure 2: Communication Between Web Proxy and ICAP Server 472 8. End-to-End Web Notification Flow 474 8.1. Step-by-Step Description of the End-to-End Web Notification Flow 476 Policy Based Routing 478 1. TCP port 80 packets from the users that need to be notified maybe 479 routed to the web proxy via policy based routing. 481 2. Packets are forwarded to the Load Balancer, which establishes a 482 session with the web proxy and routes the packets to the proxy. 484 Web Proxy 486 1. User's HTTP request is directed to the web proxy. 488 2. Web proxy received HTTP traffic and retrieves content from the 489 requested web site. 491 3. Web proxy receives response and forwards it to the ICAP server 492 for response adaptation. 494 4. The ICAP Server checks the HTTP content in order to determine 495 whether notification message can be inserted. 497 5. The ICAP Server initiates a HTTP Post to the Messaging Service 498 cache process with the IP address of the user. 500 6. If a notification message for the user exists then the 501 appropriate notification is cached on the Messaging Service. The 502 Messaging Service then returns the appropriate HTML content to 503 the ICAP Server. 505 7. 507 A. Once the notification message is retrieved from Messaging 508 Service cache the ICAP server may insert the notification 509 message in the HTTP response body without altering or 510 modifying the original content of the HTTP 200 OK response. 512 B. The ICAP Server then sends the response back to the web 513 proxy, which in turn forwards the HTTP 200 OK response back 514 to the browser. 516 8. If the user IP is not found or provisioned for a notification 517 message, then the ICAP Server should return a '204 No 518 modifications needed' response to the ICAP Client as defined in 519 section 4.3.3 of [RFC3507]. As a result, the user will not 520 receive any web notification message. 522 9. The user observes the web notification, and clicks an appropriate 523 option, such as: OK/acknowledged, snooze/ remind me later, etc. 525 8.2. Diagram of the End-to-End Web Notification Flow 527 This flow shows the communications flow from the web client, through 528 the entire system. 530 ICAP ICAP Message Customer 531 Browser Proxy Client Server Service Internet DB 532 | HTTP | | | | | | 533 | GET | | Proxy | | | | 534 +------->| | Request | | | | 535 | +---------|---------|--------|------->| | 536 | | | | 200 OK | | | 537 | |<--------|---------|--------|--------+ | 538 | | ICAP | | | | | 539 | | RESPMOD | ICAP | | | | 540 | +-------->| RESPMOD | | | | 541 | | +-------->| | | | 542 | | | | Check | | | 543 | | | | Cache | | | 544 | | | | for IP | | Cache | 545 | | | | Match | | Miss | 546 | | | +------->| | Request| 547 | | | | | | Type | 548 | | | | +--------|------->| 549 | | | Cache | | | | 550 | | | Miss | | | | 551 | | | No | | | | 552 | | | Insert | | | | 553 | |<--------|---------|--------+ |Type | 554 | 200 OK | | | | |Returned| 555 | No | | | |<-------|--------+ 556 | Insert | | | | | | 557 |<-------+ | | | | | 558 | | | Cache | | | | 559 | | | Hit | | | | 560 | | | Insert | | | | 561 | 200 OK |<--------|---------|--------+ | | 562 | Insert | | | | | | 563 |<-------+ | | | | | 564 | | | HTTP | | | | 565 | | | GET to | | | | 566 | | | Content | | | | 567 | | | Portal | | | | 568 +--------|---------|---------|--------|------->| | 569 | | | 200 OK | | | | 570 | | | w/ | | | | 571 | | | Notify | | | | 572 |<-------|---------|---------|--------|--------+ | 573 | | | | | | | 575 Figure 3: End-to-End Web Notification Flow 577 9. Example HTTP Headers for a Web Notification 579 Web-Browser HTTP Headers 581 ---------------------------------------------- 582 1. HTTP Get Request to www.example.com 583 ---------------------------------------------- 585 http://www.example.com/ 587 GET / HTTP/1.1 588 Host: www.example.com 589 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) 590 Gecko/20080404 Firefox/2.0.0.14 591 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 592 Accept-Language: en-us,en;q=0.5 593 Accept-Encoding: gzip,deflate 594 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 595 Keep-Alive: 300 596 Connection: keep-alive 597 Pragma: no-cache 599 ---------------------------------------------- 600 2. Response from www.example.com via PROXY 601 ---------------------------------------------- 603 HTTP/1.x 200 OK 604 Date: Thu, 08 May 2008 16:26:29 GMT 605 Server: Apache/2.2.3 (CentOS) 606 Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT 607 Etag: "b80f4-1b6-80bfd280" 608 Accept-Ranges: bytes 609 Content-Length: 438 610 Connection: close 611 Content-Type: text/html; charset=UTF-8 612 Age: 18 613 X-Cache: HIT from localhost.localdomain 614 Via: 1.0 localhost.localdomain (squid/3.0.STABLE5) 615 Proxy-Connection: keep-alive 617 ----------------------------------------------------------- 618 3. Example of JavaScript containing Notification Insertion 619 ----------------------------------------------------------- 621 623 634 649 ---------------------------------------------- 651 Figure 4 653 10. Deployment Considerations 655 The components of such a web notification system should be 656 distributed throughout a network, close to users. When distributed 657 in such a manner, this ensures that performance remains acceptable 658 across a wide geography. It is also a best practice that a HTTP- 659 aware load balancer is used in each datacenter where servers are 660 located, so that traffic can be spread across N+1 servers and the 661 system can be easily scaled out. 663 11. Security Considerations 665 There are no security considerations have yet been added document. 666 Will be a focus of a future update. 668 12. IANA Considerations 670 There are no IANA considerations in this document. 672 NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO 673 PUBLICATION. 675 13. Acknowledgements 677 The authors will probably wish to acknowledge someone's review or 678 contribution at some point, which is the purpose of this section. :-) 680 14. References 682 14.1. Normative References 684 [RFC1035] Mockapetris, P., "Domain names - implementation and 685 specification", STD 13, RFC 1035, November 1987. 687 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 688 Translator (NAT)", RFC 1631, May 1994. 690 [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup 691 Language - 2.0", RFC 1866, November 1995. 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, March 1997. 696 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 697 Resource Identifiers (URI): Generic Syntax", RFC 2396, 698 August 1998. 700 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 701 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 702 October 1998. 704 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 705 "Definition of the Differentiated Services Field (DS 706 Field) in the IPv4 and IPv6 Headers", RFC 2474, 707 December 1998. 709 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 710 and W. Weiss, "An Architecture for Differentiated 711 Services", RFC 2475, December 1998. 713 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 714 "Assured Forwarding PHB Group", RFC 2597, June 1999. 716 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 717 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 718 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 720 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 721 specifying the location of services (DNS SRV)", RFC 2782, 722 February 2000. 724 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 725 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 727 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 728 "Per Hop Behavior Identification Codes", RFC 3140, 729 June 2001. 731 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 732 J., Courtney, W., Davari, S., Firoiu, V., and D. 733 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 734 Behavior)", RFC 3246, March 2002. 736 [RFC3260] Grossman, D., "New Terminology and Clarifications for 737 Diffserv", RFC 3260, April 2002. 739 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 740 A., Peterson, J., Sparks, R., Handley, M., and E. 741 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 742 June 2002. 744 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 745 Protocol (SIP): Locating SIP Servers", RFC 3263, 746 June 2002. 748 [RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation 749 Protocol (ICAP)", RFC 3507, April 2003. 751 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 752 April 2006. 754 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 755 Guidelines for DiffServ Service Classes", RFC 4594, 756 August 2006. 758 14.2. Informative References 760 [CableLabs DOCSIS] 761 CableLabs, "Data-Over-Cable Service Interface 762 Specifications", CableLabs Specifications Various DOCSIS 763 Reference Documents, . 766 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 767 BCP 60, RFC 3360, August 2002. 769 Appendix A. Document Change Log 771 [RFC Editor: This section is to be removed before publication] 773 -00 version: 775 o -01 - updated doc to reflect that this system is deployed and not 776 in development, closing out two open issues. Added reference for 777 JavaScript, closing an open issue. 779 o -00 - first version published 781 Appendix B. Open Issues 783 1 - MAJOR: Add content to Security Considerations 785 2 - MINOR: Consider adding an informative reference to 786 draft-oreirdan-mody-bot-remediation when this document is completed 788 3 - MINOR: Update BVL's contact info 790 Authors' Addresses 792 Chae Chung 793 Comcast Cable Communications 794 One Comcast Center 795 1701 John F. Kennedy Boulevard 796 Philadelphia, PA 19103 797 US 799 Email: chae_chung@cable.comcast.com 800 URI: http://www.comcast.com 801 Alex Kasyanov 802 Comcast Cable Communications 803 One Comcast Center 804 1701 John F. Kennedy Boulevard 805 Philadelphia, PA 19103 806 US 808 Email: alexander_kasyanov@cable.comcast.com 809 URI: http://www.comcast.com 811 Jason Livingood 812 Comcast Cable Communications 813 One Comcast Center 814 1701 John F. Kennedy Boulevard 815 Philadelphia, PA 19103 816 US 818 Email: jason_livingood@cable.comcast.com 819 URI: http://www.comcast.com 821 Nirmal Mody 822 Comcast Cable Communications 823 One Comcast Center 824 1701 John F. Kennedy Boulevard 825 Philadelphia, PA 19103 826 US 828 Email: nirmal_mody@cable.comcast.com 829 URI: http://www.comcast.com 831 Brian Van Lieu 832 Comcast Cable Communications 833 One Comcast Center 834 1701 John F. Kennedy Boulevard 835 Philadelphia, PA 19103 836 US 838 Email: brian_vanlieu@cable.comcast.com 839 URI: http://www.comcast.com