One document matched: draft-livingood-web-notification-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- References are listed here so that they can be called via Entity attributes later -->
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1631 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1631.xml">
<!ENTITY RFC1866 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1866.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2396 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2396.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC2915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2915.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY RFC3507 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3507.xml">
<!ENTITY RFC2474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC2475 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC2597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2597.xml">
<!ENTITY RFC3140 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3140.xml">
<!ENTITY RFC3246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3246.xml">
<!ENTITY RFC3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml">
<!ENTITY RFC4594 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4594.xml">
<!ENTITY RFC3360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3360.xml">
<!ENTITY RFC4329 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4329.xml">
]>
<!-- ADD THIS ABOVE ONCE I-D IS PUBLISHED: rfc include="reference.I-D.draft-oreirdan-mody-bot-remediation-00" -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- PROCESSING INSTRUCTIONS - GENERAL -->
<!-- EACH ONE STARTS WITH '?' BELOW -->
<!-- give errors on I-D nits and perform DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc strict='yes' ?>
<?rfc toc='yes'?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth='4'?>
<!-- END GENERAL PROCESSING -->
<!-- PROCESSING INSTRUCTIONS - CONTROL OF REFERENCES -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs='yes'?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space -->
<?rfc sortrefs='yes' ?>
<!-- do not start each main section on a new page -->
<?rfc compact='yes' ?>
<!-- keep one blank line between list items -->
<?rfc subcompact='no' ?>
<!-- END REFERENCE PROCESSING -->
<rfc ipr='pre5378Trust200902' docName='draft-livingood-web-notification-01' category='info'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- FRONT SECTION -->
<front>
<title abbrev='Example of an ISP Web Notification System'>
Example of an ISP Web Notification System
</title>
<!-- add role='editor' attribute to author tag below for the editors if appropriate -->
<author initials='C.' surname='Chung' fullname='Chae Chung'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>chae_chung@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='A.' surname='Kasyanov' fullname='Alex Kasyanov'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>alexander_kasyanov@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='J.' surname='Livingood' fullname='Jason Livingood'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>jason_livingood@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='N.' surname='Mody' fullname='Nirmal Mody'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>nirmal_mody@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='B.' surname='Van Lieu' fullname='Brian Van Lieu'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>brian_vanlieu@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<date day='11' month='February' year='2010'/>
<!-- META-DATA DECLARATIONS -->
<area></area>
<!-- WG name at the upperleft corner of the doc; 'Internet Engineering Task Force' is fine for individual submissions. -->
<workgroup>Internet Engineering Task Force</workgroup>
<!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. -->
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<keyword>notification</keyword>
<keyword>Comcast</keyword>
<keyword>ISP</keyword>
<keyword>Internet Service Provider</keyword>
<keyword>bot remediation</keyword>
<keyword>bot notification</keyword>
<abstract>
<t>The objective of this document is to describe one method of providing notifications to web browsers that has been deployed by Comcast, a large Internet Service Provider (ISP). Such a notification system can be used by an ISP to provide near-immediate notifications to their users, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection, for example. There are many proprietary systems that can perform such notifications on the market today, some of which use inline-based Deep Packet Inspection (DPI) systems. This document describes one example of such a system that does not rely upon DPI systems, and is instead based in open standards and open source systems. While the system described herein is in some ways specific to the Data-Over-Cable Service Interface Specifications (DOCSIS) networks used by most cable-based broadband ISPs, components and concepts described in this document can generally be applied to many different types of networks.</t>
</abstract>
<!-- END META-DATA DECLARATIONS -->
</front>
<!-- END FRONT SECTION -->
<!-- MIDDLE SECTION -->
<middle>
<section anchor='ReqLang' title='Requirements Language' toc='include'>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor='intro' title='Introduction' toc='include'>
<t>Internet Service Providers (ISPs) have a need for a system that is capable of communicating with selected customers in a nearly immediate manner. Given the prevalence of the web browser as the predominant client software in use by Internet users, the web browser is an ideal vehicle for providing notifications. This document describes a system that has been deployed by Comcast, a large broadband ISP, to provide notifications to web browsers, which can be used to provide such near-immediate notifications to users. This type of system is designed to provide a non-intrusive, though obvious, notification to a user's web browser.</t>
<t>In evaluating potential solutions, most commercially available systems were either proprietary and/or required inline-based Deep Packet Inspection (DPI) systems. However, Comcast and many other ISPs may desire to use a system based on open standards, non-proprietary software, and which does not require the use of DPI. While the system described herein is specific to the Data-Over-Cable Service Interface Specifications (DOCSIS, <xref target="CableLabs DOCSIS"/>) networks used by most cable-based broadband ISPs, components and concepts described in this document can generally be applied to many different types of networks.</t>
</section>
<section title='High-Level Design of the System' toc='include'>
<t>The web notification system design is based on the use of the Internet Content Adaptation Protocol <xref target="RFC3507"/>. The design uses open source applications such as the Squid Web Proxy, the GreasySpoon ICAP server, and Apache Tomcat. The ICAP protocol allows for message transformation or adaptation. An ICAP client passes a HyperText Transport Protocol (HTTP, <xref target="RFC2616"/>) message to an ICAP server for some type of processing. The ICAP Server will in turn respond back to the client with the modified HTTP message containing the notification message.</t>
<t>Message modification itself may then be provided via either a HTTP request or HTTP response. However, for the specific system described in this document, only the HTTP response is modified, by using the 'respmod' method defined in Section 3.2 of <xref target="RFC3507"/>.</t>
</section>
<section anchor='requirements' title='Design Requirements' toc='include'>
<t>This section describes all of the requirements taken into consideration for the design of this system.</t>
<section title='General'>
<t>
<list style="format REQ%d:" counter="design_requirements_count">
<t>TCP Port 80: The system should provide notifications via TCP port 80, the well-known port for HTTP traffic.</t>
<t>Whitelisting: It is possible that the HyperText Markup Language (HTML, <xref target="RFC1866"/>) or JavaScript <xref target="RFC4329"/> used for notifications may cause problems for access to a particular website. Therefore, such a system should be capable of using a whitelist of website Uniform Resource Indicators (URIs, <xref target="RFC2396"/>) or Fully Qualified Domain Named (FQDNs, Section 5.1 of <xref target="RFC1035"/>) that conflict with the system, to instruct the system to not provide a notifications related to certain sites, in order to reduce any errors or unexpected results.</t>
<t>Instant Messaging (IM): Some IM clients use TCP port 80 in their communications, often as an alternate port when standard, well-known ports do not work. This system should not conflict with or cause unexpected results for IM clients. </t>
<t>Handling of Active Sessions: To the extent that a web notification system must temporarily route TCP port 80 traffic, in order to provide a notification, previously active TCP port 80 sessions should be maintained.</t>
<t>No TCP Resets: The use of TCP resets has been widely criticized, both in the Internet community generally as well as in <xref target='RFC3360'/>. As such, except for the case of unintentional errors, the use of TCP resets must not be used.</t>
<t>Non-Disruptive: The web notification system should not disrupt the end user experience, such as causing significant clients errors.</t>
<t>Notification Acknowledgement: Once a user responds and acknowledges a notification, the notification should immediately stop, so it is not repeatedly and annoyingly presented, again and again, in a short period of time.</t>
<t>Non-Modification of Content: Such a system should not significantly alter the content of any website the user is accessing.</t>
<t>Unexpected Content: The system should transparently handle traffic for which it cannot provide a web notification. Thus, widely varying content should be expected, and all such unexpected traffic should be able to be handled by the system without generating errors or unexpected results.</t>
<t>No Caching: Web content must not be cached by the system.</t>
<t>No Advertising Replacement or Insertion: The system must not be used to replace any advertising provided by a website, or insert advertising into websites where none was intended by the owner of a given website.</t>
</list>
</t>
</section>
<section title='Web Proxy'>
<t>
<list style="format REQ%d:" counter="design_requirements_count">
<t>Open-Source Software: The system should use an open source web proxy server, such as Squid. (While it is possible to use any web proxy, the use of open source, and openly documented software is recommended.)</t>
<t>ICAP Client: The web proxy server should have an integrated ICAP client.</t>
<t>Access Control: Access to the proxy should be limited exclusively to the IP addresses of users for which notifications are intended, and only for limited periods of time. Furthermore, if a Session Management Broker (SMB) is utilized, as described in <xref target='Functional-Components-Described'/> below, then the proxy should restrict access only to the IP of the SMB.</t>
</list>
</t>
</section>
<section title='ICAP Server'>
<t>
<list style="format REQ%d:" counter="design_requirements_count">
<t>Request and Response Support: The system should support both request and response adaptation.</t>
<t>Consistency: The system must be able to consistently provide a specific notification.</t>
<t>Multiple Notification Types: The system must be able to provide many different types of notifications.</t>
<t>Simultaneous Differing Notifications: The system must be able to simultaneously serve multiple notifications, including notifications of varying types, to different users. As a result, User A should be able to get the notification intended specifically for User A, at the same time that User B receives an entirely different notification, which was intended specifically for User B.</t>
</list>
</t>
</section>
<section title='Messaging Service'>
<t>
<list style="format REQ%d:" counter="design_requirements_count">
<t>Messaging Service: The Messaging Service, as described in <xref target='Functional-Components-Described'/> below caches the notifications for each specific user. Thus, by caching the notification messages, the system may provide notifications without significantly affecting the web browsing experience of the user.</t>
<t>Process Acknowledgements: The Messaging Service should process acknowledgements to properly remove entries from the cache and forward acknowledgements to the Messaging Service.</t>
<t>Ensure Notification Targeting Accuracy: The Messaging Service must ensure that notifications are presented to the intended users.</t>
<t>Keep Records for Customer Care: The Messaging Service should maintain some type of record that a notification has been presented and/or acknowledged, in case a user inquires with customer care personnel.</t>
</list>
</t>
</section>
</section>
<section title='Functional Overview' toc='include'>
<t>This section defines the various core functional components of the system. These components are then shown in a diagram to describe how the various components are linked and relate to one another.</t>
<section title='Functional Components Described' anchor='Functional-Components-Described'>
<t>It should be noted that when specific software cited is but one example of a possible selection for each component. As the state of the art changes, so too many the best or most appropriate software choices here vary.
<list style="format 5.1.%C.">
<t>Web Proxy: A standard web proxy server. The initial version of this system uses the Squid Proxy, an open source application in wide use.</t>
<t>ICAP Server: This should be an open source application capable of supporting content adaptation in both request and response modes. The ICAP Server retrieves the notifications from the Messaging service cache when content adaption is needed. The initial version of this system uses GreasySpoon, an open source application.</t>
<t>Customer Database: The Customer Database holds the user information including the notifications setup for each user. The database may also hold status of which users were notified and users pending notification.</t>
<t>The Messaging Service is a process engine that retrieves specific web notification messages from a catalog of possible notifications. When a notification for a specific user is not in cache, the process retrieves this information from the Customer Database and populates the cache for a specific period of time. The initial version of this service uses Apache Tomcat, an open source application.</t>
<t>Session Management Broker: A Load Balancer (LB) with a customized layer 7 inspection policy was used to differentiate between HTTP and non-HTTP traffic on TCP port 80. The LB functions as a full stateful TCP proxy with the ability to forward packets from existing TCP sessions that do not exist in the internal session table. New HTTP sessions are load balanced to a proxy layer either transparently or using source Network Address Translation (NAT <xref target="RFC1631"/>) from the LB, with additional layer 7 inspection as needed. Established TCP sessions not in the LB session table are simply forwarded to the destination transparently via the proxy layer. The initial version of this system uses a Session Management Broker which has been developed internally by Comcast.</t>
</list>
</t>
</section>
<section title='Functional Diagram'>
<figure anchor='Web Notification System - Functional Components' title='Web Notification System - Functional Components'>
<artwork><![CDATA[
+--------+ +------------+ +----------+
| ICAP | <----> | Messaging | <----> | Customer |
| Server | | Service | | Database |
+--------+ +------------+ +----------+
^
| +----------+
| | |
| +-------> | Internet | <-------+
| | | | |
| | +----------+ |
| | ^ |
| | | |
v v | |
+----------+ V v
|+--------+| +-------+ +--------+
|| ICAP || <----> | SMB | <---> | Access |
|| Client || +-------+ | Router |
|+--------+| +--------+
|| SQUID || ^
|| Proxy || |
|+--------+| |
+----------+ |
v
+----------+
| Network |
| Element* |
+----------+
^
|
|
v
+------+
| PC |
+------+
* An access network element, such as a Cable Modem Termination
System (CMTS).
]]></artwork>
</figure>
</section>
</section>
<section title='High Level Communication Flow' toc='include'>
<t>
<list style="format 6.%C.">
<t>Setup Differentiated Services (DiffServ): Using DiffServe <xref target="RFC2474" /> <xref target="RFC2475" /> <xref target="RFC2597" /> <xref target="RFC3140" /> <xref target="RFC3246" /> <xref target="RFC3260" /> <xref target="RFC4594" />, set a policy to direct TCP port 80 traffic to the web notification system's web proxy.</t>
<t>Session Management: TCP port 80 Packets are routed to a load balancer where the load balancer then distinguishes new TCP port 80 sessions as HTTP or non-HTTP. For HTTP sessions, the load balancer forwards to the proxy. For non-HTTP traffic such as instant messaging (IM), the load balancer either forwards to a TCP proxy layer for handling or operates as a full TCP proxy for non-HTTP sessions and forwards to the destination. Pre-established TCP sessions on port 80 are identified by the load balancer and forwarded with no impact.</t>
<t>Web Proxy Forwards Request: The web proxy forwards the HTTP request on to the destination site, as a web proxy normally would do.</t>
<t>On Response, Send Message to ICAP Server: When the HTTP response is received, the web proxy sends a message to the ICAP server for the web notification.</t>
<t>Messaging Service: Messaging Service should respond with appropriate notification content or null response if notification is not cached.</t>
<t>ICAP Server Responds: The ICAP server responds and furnishes the appropriate content of the appropriate web notification to the web proxy.</t>
<t>Web Proxy Sends Response: The web proxy then sends a "200 OK" HTTP message to the original web client, containing the originally requested content and the web notification.</t>
<t>User Response: The user observes the web notification, and clicks an appropriate option, such as: OK/acknowledged, snooze/remind me later, etc.</t>
<t>More Information: Depending upon the notification, the user may be provided with more information. Using the example of a web notification to a user explaining that it is highly likely that they have been infected with a virus or malware, the user may click an acknowledgement that indicates that clicking that will take them to a page with information about virus/malware scanning and remediation.</t>
<t>Turn Down DiffServ: Once the notification transaction has completed, remove any special DiffServ settings.</t>
</list>
</t>
</section>
<section title='Communication Between Web Proxy and ICAP Server' toc='include'>
<figure anchor='Communication Between Web Proxy and ICAP Server' title='Communication Between Web Proxy and ICAP Server'>
<artwork><![CDATA[
+------------+
| |
| www URL |
| |
+------------+
^ |
| |
(2)| |(3)
| |
| v
+--------+ (4) +--------+ (4) +--------+
| |------------>| |------------>| |
| | | | | |
| | (5) | | (5) | |
| |<------------| |<------------| |
| Proxy | | ICAP | | ICAP |
| Module | (6) | Client | (6) | Server |
| |------------>| |------------>| |
| | | | | |
| | (7) | | (7) | |
| |<------------| |<------------| |
+--------+ +--------+ +--------+
^ |
| |
(1)| |(8)
| |
| v
+------------+ (9) +------------+
| |----------------------------->| |
| | | |
| Browser | | Web Server |
| | (10) | |
| |<-----------------------------| |
+------------+ +------------+
(1) - HTTP GET (TCP 80)
(2) - Proxy HTTP GET (TCP 80)
(3) - HTTP 200 OK w/ Response
(4) - ICAP RESPMOD
(5) - ICAP 200 OK
(6) - TCP Stream - Encapsulate Header
(7) - ICAP 200 OK Insert Message
(8) - HTTP 200 OK w/ Response + Message Frame
(9) - HTTP GET for Message
(10) - HTTP 200 w/ Message Content
]]></artwork>
</figure>
</section>
<section title='End-to-End Web Notification Flow' toc='include'>
<section title='Step-by-Step Description of the End-to-End Web Notification Flow'>
<t>Policy Based Routing
<list style="numbers">
<t>TCP port 80 packets from the users that need to be notified maybe routed to the web proxy via policy based routing.</t>
<t>Packets are forwarded to the Load Balancer, which establishes a session with the web proxy and routes the packets to the proxy.</t>
</list>
</t>
<t>Web Proxy
<list style="numbers">
<t>User's HTTP request is directed to the web proxy.</t>
<t>Web proxy received HTTP traffic and retrieves content from the requested web site.</t>
<t>Web proxy receives response and forwards it to the ICAP server for response adaptation.</t>
<t>The ICAP Server checks the HTTP content in order to determine whether notification message can be inserted.</t>
<t>The ICAP Server initiates a HTTP Post to the Messaging Service cache process with the IP address of the user.</t>
<t>If a notification message for the user exists then the appropriate notification is cached on the Messaging Service. The Messaging Service then returns the appropriate HTML content to the ICAP Server.</t>
<t>
<list style="letters">
<t>Once the notification message is retrieved from Messaging Service cache the ICAP server may insert the notification message in the HTTP response body without altering or modifying the original content of the HTTP 200 OK response.</t>
<t>The ICAP Server then sends the response back to the web proxy, which in turn forwards the HTTP 200 OK response back to the browser.</t>
</list>
</t>
<t>If the user IP is not found or provisioned for a notification message, then the ICAP Server should return a '204 No modifications needed' response to the ICAP Client as defined in section 4.3.3 of [RFC3507]. As a result, the user will not receive any web notification message. </t>
<t>The user observes the web notification, and clicks an appropriate option, such as: OK/acknowledged, snooze/ remind me later, etc.</t>
</list>
</t>
</section>
<section title='Diagram of the End-to-End Web Notification Flow'>
<t>This flow shows the communications flow from the web client, through the entire system.</t>
<figure anchor='End-to-End Web Notification Flow' title='End-to-End Web Notification Flow'>
<artwork><![CDATA[
ICAP ICAP Message Customer
Browser Proxy Client Server Service Internet DB
| HTTP | | | | | |
| GET | | Proxy | | | |
+------->| | Request | | | |
| +---------|---------|--------|------->| |
| | | | 200 OK | | |
| |<--------|---------|--------|--------+ |
| | ICAP | | | | |
| | RESPMOD | ICAP | | | |
| +-------->| RESPMOD | | | |
| | +-------->| | | |
| | | | Check | | |
| | | | Cache | | |
| | | | for IP | | Cache |
| | | | Match | | Miss |
| | | +------->| | Request|
| | | | | | Type |
| | | | +--------|------->|
| | | Cache | | | |
| | | Miss | | | |
| | | No | | | |
| | | Insert | | | |
| |<--------|---------|--------+ |Type |
| 200 OK | | | | |Returned|
| No | | | |<-------|--------+
| Insert | | | | | |
|<-------+ | | | | |
| | | Cache | | | |
| | | Hit | | | |
| | | Insert | | | |
| 200 OK |<--------|---------|--------+ | |
| Insert | | | | | |
|<-------+ | | | | |
| | | HTTP | | | |
| | | GET to | | | |
| | | Content | | | |
| | | Portal | | | |
+--------|---------|---------|--------|------->| |
| | | 200 OK | | | |
| | | w/ | | | |
| | | Notify | | | |
|<-------|---------|---------|--------|--------+ |
| | | | | | |
]]></artwork>
</figure>
</section>
</section>
<section title='Example HTTP Headers for a Web Notification' toc='include'>
<figure anchor='Example HTTP Headers for a Web Notification'>
<!-- <preamble>Figure 1: Example HTTP Headers for a Web Notification</preamble>-->
<artwork><![CDATA[
Web-Browser HTTP Headers
----------------------------------------------
1. HTTP Get Request to www.example.com
----------------------------------------------
http://www.example.com/
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
----------------------------------------------
2. Response from www.example.com via PROXY
----------------------------------------------
HTTP/1.x 200 OK
Date: Thu, 08 May 2008 16:26:29 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Age: 18
X-Cache: HIT from localhost.localdomain
Via: 1.0 localhost.localdomain (squid/3.0.STABLE5)
Proxy-Connection: keep-alive
-----------------------------------------------------------
3. Example of JavaScript containing Notification Insertion
-----------------------------------------------------------
<!--all elements used in a notification should have css properties
defined to avoid unwanted inheritance from parent page-->
<style type="text/css">
#example {
position: absolute; left: 100px; top: 50px;
z-index: 9999999; height: auto; width: 550px;
padding: 10px;
border: solid 2px black;
background-color:#FDD017;
opacity: 0.8; filter: alpha(opacity = 80);
}
</style>
<script language="javascript" type="text/javascript">
// ensure that content is not part of an iframe
if (self.location == top.location) {
// this is a floating div with 80% transparency
document.write('<div id="example" name="example">');
document.write('<h2>IMPORTANT MESSAGE</h2>');
document.write('<p>Lorem ipsum dolor sit amet, consecteteur ');
document.write('adipisicing elit, sed do eiusmod tempor ');
document.write('incididunt ut labore et dolore magna aliqua. ');
document.write('Ut enim ad minim veniam, quis nostrud ');
document.write('exercitation ullamco laboris nisi ut aliquip ex ');
document.write('ea commodo consequat.');
document.write('</div>');
}</script>
----------------------------------------------
]]></artwork>
</figure>
</section>
<section title='Deployment Considerations' toc='include'>
<t>The components of such a web notification system should be distributed throughout a network, close to users. When distributed in such a manner, this ensures that performance remains acceptable across a wide geography. It is also a best practice that a HTTP-aware load balancer is used in each datacenter where servers are located, so that traffic can be spread across N+1 servers and the system can be easily scaled out.</t>
</section>
<section title='Security Considerations' toc='include'>
<t>There are no security considerations have yet been added document. Will be a focus of a future update.</t>
</section>
<section title='IANA Considerations' toc='include'>
<t>There are no IANA considerations in this document.</t>
<t>NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO PUBLICATION.</t>
</section>
<section title='Acknowledgements' toc='include'>
<t>The authors will probably wish to acknowledge someone's review or contribution at some point, which is the purpose of this section. :-)</t>
</section>
<!-- appendix -->
</middle>
<!-- END MIDDLE SECTION -->
<!-- BACK SECTION -->
<back>
<references title="Normative References">
&RFC1035;
&RFC1631;
&RFC1866;
&RFC2119;
&RFC2396;
&RFC2434;
&RFC2616;
&RFC2782;
&RFC2915;
&RFC3261;
&RFC3263;
&RFC3507;
&RFC2474;
&RFC2475;
&RFC2597;
&RFC3140;
&RFC3246;
&RFC3260;
&RFC4329;
&RFC4594;
</references>
<references title='Informative References'>
&RFC3360;
<reference anchor="CableLabs DOCSIS" target="http://www.cablelabs.com/specifications/archives/docsis.html">
<front>
<title>Data-Over-Cable Service Interface Specifications</title>
<author fullname="Various">
<organization>CableLabs</organization>
</author>
</front>
<seriesInfo name="CableLabs Specifications" value="Various DOCSIS Reference Documents"/>
</reference>
</references>
<section title='Document Change Log'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>-00 version:
<list style='symbols'>
<t>-01 - updated doc to reflect that this system is deployed and not in development, closing out two open issues. Added reference for JavaScript, closing an open issue.</t>
<t>-00 - first version published</t>
</list>
</t>
</section>
<section title='Open Issues'>
<t>1 - MAJOR: Add content to Security Considerations</t>
<t>2 - MINOR: Consider adding an informative reference to draft-oreirdan-mody-bot-remediation when this document is completed</t>
<t>3 - MINOR: Update BVL's contact info</t>
</section>
</back>
<!-- END BACK SECTION -->
</rfc>
<!-- FOR REFERENCE -->
<!-- less than is < -->
<!-- ampersand is & -->
<!-- apostrophe is &apos -->
<!-- quotation is " -->
| PAFTECH AB 2003-2026 | 2026-04-24 13:39:17 |