Internet Engineering Task Force C. Chung
Internet-Draft A. Kasyanov
Intended status: Informational J. Livingood
Expires: September 6, 2010 N. Mody
Comcast
B. Van Lieu
Unaffiliated
March 5, 2010
Example of an ISP Web Notification System
draft-livingood-web-notification-02
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
Chung, et al. Expires September 6, 2010 [Page 1]
Internet-Draft Example of an ISP Web Notification System March 2010
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Chung, et al. Expires September 6, 2010 [Page 2]
Internet-Draft Example of an ISP Web Notification System March 2010
Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High-Level Design of the System . . . . . . . . . . . . . . . 4
4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. ICAP Server . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Messaging Service . . . . . . . . . . . . . . . . . . . . 7
5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7
5.1. Functional Components Described . . . . . . . . . . . . . 7
5.2. Functional Diagram . . . . . . . . . . . . . . . . . . . . 9
6. High Level Communication Flow . . . . . . . . . . . . . . . . 9
7. Communication Between Web Proxy and ICAP Server . . . . . . . 11
8. End-to-End Web Notification Flow . . . . . . . . . . . . . . . 11
8.1. Step-by-Step Description of the End-to-End Web
Notification Flow . . . . . . . . . . . . . . . . . . . . 12
8.2. Diagram of the End-to-End Web Notification Flow . . . . . 13
9. Example HTTP Headers for a Web Notification . . . . . . . . . 15
10. Deployment Considerations . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 19
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Chung, et al. Expires September 6, 2010 [Page 3]
Internet-Draft Example of an ISP Web Notification System March 2010
1. Requirements Language
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 RFC 2119 [RFC2119].
2. Introduction
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.
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, [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.
3. High-Level Design of the System
The web notification system design is based on the use of the
Internet Content Adaptation Protocol [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, [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.
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 [RFC3507].
Chung, et al. Expires September 6, 2010 [Page 4]
Internet-Draft Example of an ISP Web Notification System March 2010
4. Design Requirements
This section describes all of the requirements taken into
consideration for the design of this system.
4.1. General
REQ1: TCP Port 80: The system should provide notifications via TCP
port 80, the well-known port for HTTP traffic.
REQ2: Whitelisting: It is possible that the HyperText Markup
Language (HTML, [RFC1866]) or JavaScript [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,
[RFC2396]) or Fully Qualified Domain Named (FQDNs, Section
5.1 of [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.
REQ3: 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.
REQ4: 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.
REQ5: No TCP Resets: The use of TCP resets has been widely
criticized, both in the Internet community generally as well
as in [RFC3360]. As such, except for the case of
unintentional errors, the use of TCP resets must not be used.
REQ6: Non-Disruptive: The web notification system should not
disrupt the end user experience, such as causing significant
clients errors.
REQ7: 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.
REQ8: Non-Modification of Content: Such a system should not
significantly alter the content of any website the user is
accessing.
Chung, et al. Expires September 6, 2010 [Page 5]
Internet-Draft Example of an ISP Web Notification System March 2010
REQ9: 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.
REQ10: No Caching: Web content must not be cached by the system.
REQ11: 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.
4.2. Web Proxy
REQ12: 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.)
REQ13: ICAP Client: The web proxy server should have an integrated
ICAP client.
REQ14: 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 Section 5.1 below, then the proxy
should restrict access only to the IP of the SMB.
4.3. ICAP Server
REQ15: Request and Response Support: The system should support both
request and response adaptation.
REQ16: Consistency: The system must be able to consistently provide
a specific notification.
REQ17: Multiple Notification Types: The system must be able to
provide many different types of notifications.
REQ18: 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.
Chung, et al. Expires September 6, 2010 [Page 6]
Internet-Draft Example of an ISP Web Notification System March 2010
4.4. Messaging Service
REQ19: Messaging Service: The Messaging Service, as described in
Section 5.1 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.
REQ20: Process Acknowledgements: The Messaging Service should
process acknowledgements to properly remove entries from the
cache and forward acknowledgements to the Messaging Service.
REQ21: Ensure Notification Targeting Accuracy: The Messaging Service
must ensure that notifications are presented to the intended
users.
REQ22: 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.
5. Functional Overview
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.
5.1. Functional Components Described
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.
5.1.A. Web Proxy: A standard web proxy server. The initial version
of this system uses the Squid Proxy, an open source
application in wide use.
5.1.B. 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.
Chung, et al. Expires September 6, 2010 [Page 7]
Internet-Draft Example of an ISP Web Notification System March 2010
5.1.C. 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.
5.1.D. The Messaging Service is a process engine that retrieves
specific web notification messages from a catalog of possible
notifications. A 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.
5.1.E. 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 [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.
Chung, et al. Expires September 6, 2010 [Page 8]
Internet-Draft Example of an ISP Web Notification System March 2010
5.2. Functional Diagram
+--------+ +------------+ +----------+
| 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).
Figure 1: Web Notification System - Functional Components
6. High Level Communication Flow
Chung, et al. Expires September 6, 2010 [Page 9]
Internet-Draft Example of an ISP Web Notification System March 2010
6.A. Setup Differentiated Services (DiffServ): Using DiffServe
[RFC2474] [RFC2475] [RFC2597] [RFC3140] [RFC3246] [RFC3260]
[RFC4594], set a policy to direct TCP port 80 traffic to the
web notification system's web proxy.
6.B. 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.
6.C. Web Proxy Forwards Request: The web proxy forwards the HTTP
request on to the destination site, as a web proxy normally
would do.
6.D. 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.
6.E. Messaging Service: Messaging Service should respond with
appropriate notification content or null response if
notification is not cached.
6.F. ICAP Server Responds: The ICAP server responds and furnishes
the appropriate content of the appropriate web notification to
the web proxy.
6.G. 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.
6.H. User Response: The user observes the web notification, and
clicks an appropriate option, such as: OK/acknowledged, snooze/
remind me later, etc.
6.I. 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.
Chung, et al. Expires September 6, 2010 [Page 10]
Internet-Draft Example of an ISP Web Notification System March 2010
6.J. Turn Down DiffServ: Once the notification transaction has
completed, remove any special DiffServ settings.
7. Communication Between Web Proxy and ICAP Server
+------------+
| www URL |
+------------+
^ |
(2)| |(3)
| v
+--------+ (4) +--------+ (4) +--------+
| |------------>| |------------>| |
| | (5) | | (5) | |
| Proxy |<------------| ICAP |<------------| ICAP |
| Module | (6) | Client | (6) | Server |
| |------------>| |------------>| |
| | (7) | | (7) | |
| |<------------| |<------------| |
+--------+ +--------+ +--------+
^ |
(1)| |(8)
| v
+------------+ (9) +------------+
| |----------------------------->| |
| Browser | (10) | Web Server |
| |<-----------------------------| |
+------------+ +------------+
(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
Figure 2: Communication Between Web Proxy and ICAP Server
8. End-to-End Web Notification Flow
Chung, et al. Expires September 6, 2010 [Page 11]
Internet-Draft Example of an ISP Web Notification System March 2010
8.1. Step-by-Step Description of the End-to-End Web Notification Flow
Policy Based Routing
1. TCP port 80 packets from the users that need to be notified maybe
routed to the web proxy via policy based routing.
2. Packets are forwarded to the Load Balancer, which establishes a
session with the web proxy and routes the packets to the proxy.
Web Proxy
1. User's HTTP request is directed to the web proxy.
2. Web proxy received HTTP traffic and retrieves content from the
requested web site.
3. Web proxy receives response and forwards it to the ICAP server
for response adaptation.
4. The ICAP Server checks the HTTP content in order to determine
whether notification message can be inserted.
5. The ICAP Server initiates a HTTP Post to the Messaging Service
cache process with the IP address of the user.
6. 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.
7.
A. 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.
B. 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.
8. 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.
Chung, et al. Expires September 6, 2010 [Page 12]
Internet-Draft Example of an ISP Web Notification System March 2010
9. The user observes the web notification, and clicks an appropriate
option, such as: OK/acknowledged, snooze/ remind me later, etc.
8.2. Diagram of the End-to-End Web Notification Flow
This flow shows the communications flow from the web client, through
the entire system.
Chung, et al. Expires September 6, 2010 [Page 13]
Internet-Draft Example of an ISP Web Notification System March 2010
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 | | | |
|<-------|---------|---------|--------|--------+ |
Figure 3: End-to-End Web Notification Flow
9. Example HTTP Headers for a Web Notification
Chung, et al. Expires September 6, 2010 [Page 14]
Internet-Draft Example of an ISP Web Notification System March 2010
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;
Chung, et al. Expires September 6, 2010 [Page 15]
Internet-Draft Example of an ISP Web Notification System March 2010
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>
----------------------------------------------
Figure 4
10. Deployment Considerations
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.
11. Security Considerations
This web notification system was conceived in order to provide an
additional method of notifying ISP customers that their computer was
infected with malware. Depending upon the nature of the alert
contained in the web notification, such as the malware alert, users
could fear that it is some kind of phishing attack. As a result,
care should be taken with the text and any links contained in the web
notification itself. For example, the ISP may find it best to
provide a general URI or a telephone number. In contrast to that,
the ISP should not ask for login credentials or for someone to follow
a link in the web notification in order to change their password
since these are common phishing techniques. Finally, care should be
taken to provide confidence that the web notification is valid and
Chung, et al. Expires September 6, 2010 [Page 16]
Internet-Draft Example of an ISP Web Notification System March 2010
from a trusted party, and/or that the user has an alternate method of
checking the validity of the web notification.
12. IANA Considerations
There are no IANA considerations in this document.
NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO
PUBLICATION.
13. Acknowledgements
The authors wish to thank Alissa Cooper for her review of and
comments on the document, as well as others who reviewed the
document.
14. References
14.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address
Translator (NAT)", RFC 1631, May 1994.
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup
Language - 2.0", RFC 1866, November 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
Chung, et al. Expires September 6, 2010 [Page 17]
Internet-Draft Example of an ISP Web Notification System March 2010
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140,
June 2001.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3507] Elson, J. and A. Cerpa, "Internet Content Adaptation
Protocol (ICAP)", RFC 3507, April 2003.
[RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329,
April 2006.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
Chung, et al. Expires September 6, 2010 [Page 18]
Internet-Draft Example of an ISP Web Notification System March 2010
14.2. Informative References
[CableLabs DOCSIS]
CableLabs, "Data-Over-Cable Service Interface
Specifications", CableLabs Specifications Various DOCSIS
Reference Documents, <http://www.cablelabs.com/
specifications/archives/docsis.html>.
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
BCP 60, RFC 3360, August 2002.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-00 version:
o -02 - updated BVL's contact info, clearing one open issue. Also
added content to Security Considerations.
o -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.
o -00 - first version published
Appendix B. Open Issues
1 - MAJOR: Request final review by all co-authors. After this, make
any revisions in -03 and send directly to the RFC Editor.
Authors' Addresses
Chae Chung
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
US
Email: chae_chung@cable.comcast.com
URI: http://www.comcast.com
Chung, et al. Expires September 6, 2010 [Page 19]
Internet-Draft Example of an ISP Web Notification System March 2010
Alex Kasyanov
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
US
Email: alexander_kasyanov@cable.comcast.com
URI: http://www.comcast.com
Jason Livingood
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
US
Email: jason_livingood@cable.comcast.com
URI: http://www.comcast.com
Nirmal Mody
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
US
Email: nirmal_mody@cable.comcast.com
URI: http://www.comcast.com
Brian Van Lieu
Unaffiliated
Bethlehem, PA 18018
US
Email: brian@vanlieu.net
Chung, et al. Expires September 6, 2010 [Page 20]