Network Working Group M. Nottingham
Internet-Draft February 21, 2002
Expires: August 22, 2002
Web Active Resource Monitoring
draft-nottingham-webi-warm-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
WARM is a straw-man proposal for a solution to the RUP requirements
of the WEBI WG which reuses the Web Architecture (and HTTP). In
particular, it provides a mechanism for distributing cache
invalidations from HTTP servers to clients.
Nottingham Expires August 22, 2002 [Page 1]
Internet-Draft WARM February 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 WARM Resources . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Channel Resources . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Subscription Resources . . . . . . . . . . . . . . . . . . . 5
2. Overview of Operation . . . . . . . . . . . . . . . . . . . 5
2.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Active Discovery . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Passive Discovery . . . . . . . . . . . . . . . . . . . . . 6
2.2 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Subscription-Based Monitoring . . . . . . . . . . . . . . . 7
2.2.2 Polling-Based Monitoring . . . . . . . . . . . . . . . . . . 8
3. Relationships to Network Nodes . . . . . . . . . . . . . . . 9
4. Using WARM for Cache Invalidation . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
5.1 The WATCH HTTP request method . . . . . . . . . . . . . . . 10
5.2 The Subscription HTTP request header . . . . . . . . . . . . 11
5.3 The Channel HTTP response header . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
B. Issues/TODO . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
Nottingham Expires August 22, 2002 [Page 2]
Internet-Draft WARM February 2002
1. Introduction
WEBI's Resource Update Protocol requirements are broad enough that a
wide variety of architectural styles could satisfy them. WARM is a
straw-man proposal for RUP that concentrates on reusing the Web
architecture. This approach has several advantages;
o Generality - The Web is most correctly defined as an information
space, rather than the use of any particular protocol or format.
A notification protocol that uses the same foundations as the Web
(namely, resources identified by URIs and HTTP) will be able to
make statements about any resource on the Web, not just a subset
of them.
o Extensibility/Evolvability - WARM leverages the Web's properties
of extensibility and evolvability, in turn providing them to
applications that use it for notifications.
o Simplicity - A HTTP-based system is easier for Web publishers and
HTTP implementors to understand.
o Ease of Implementation - Because WARM uses the HTTP, the cost of
implementing on HTTP devices it is extremely low. Additionally,
WARM will be able to use well-understood HTTP mechanisms like
authentication, SSL/TLS, ETag validation, content negotiation,
redirection, etc.
This document defines the WARM architecture and a cache invalidation
payload for it. Please direct comments to the WEBI WG mailing list,
webi@lists.equinix.com.
1.1 Requirements
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 [2].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements. An implementation that
satisfies all the MUST or REQUIRED level and all the SHOULD level
requirements is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD
level requirements is said to be "conditionally compliant".
1.2 WARM Resources
WARM provides for propogation of events concerning Web resources by
defining two new types of resources; Channel Resources and
Nottingham Expires August 22, 2002 [Page 3]
Internet-Draft WARM February 2002
Subscription Resources.
Note that these classifications are conveniences; they are not
fundamentally different from other kinds of resources on the Web.
WARM effects monitoring by transferring representations of the state
of Channel Resources and caching it for a short period of time. If
subscription-based monitoring is in use, clients expose a
Subscription Resource, into which representations of the Channel
Resource's state are copied. Clients using Polling-based monitoring
will directly fetch a representation of the Channel Resource's state
and cache it locally.
Representations of Channel Resources (whether polled or subscribed)
have a freshness associated with them, which is functionally similar
to HTTP cache freshness. When they become stale, any assertions made
by the representations SHOULD be considered invalid.
On their own, these mechanisms allow the transfer of state
representations in the channel and subscriptions to it; they do not
describe what the representations of that state are. This
specification defines one representation format that can be used to
maintain coherence in an HTTP cache; other payloads may be defined in
the future.
1.2.1 Channel Resources
Channel Resources characterize the state of an arbitrary grouping of
Web resources. They are are identified by URIs, are accessed using
the HTTP, and can be monitored either by polling or through
subscription.
Traditional Web resources may be monitored using the same mechanisms;
they behave as Channel Resources that characterize the state of only
one Web resource.
For example, the Channel Resource
http://www.example.com/channel;A
embodies a channel that contains the state of an arbitrary number of
resources. Those resources may be under control of the same
authority as the Channel Resource, or they may be elsewhere.
Informally, the semantics of common HTTP methods on Channel Resources
are:
o GET - retrieve a representation of the state of the channel.
Nottingham Expires August 22, 2002 [Page 4]
Internet-Draft WARM February 2002
o WATCH - subscribe to the channel.
1.2.2 Subscription Resources
When a Channel Resource is subscribed to using the WATCH method, a
reference to a Subscription Resource is provided in the Subscription
HTTP request header. This allows the Channel Resource to maintain
state regarding who is subscribed, and to locate them to perform
operations related to the subscription.
For example, a Subscription Resource
http://client.example.net/subscription;1
contains the state associated with a particular subscription to the
Channel Resource. Subscription resources might be accessed through
any number of protocols; this document only defines how they are
accessed in HTTP.
Informally, the semantics of common HTTP methods on Subscription
Resources are:
o GET - retrieve a representation of the state of the subscription.
o PUT - replace the state of the subscription.
o POST - update the freshness of the subscription.
o DELETE - terminate the subscription.
2. Overview of Operation
WARM's operation is composed of two different modes; discovery and
monitoring.
2.1 Discovery
The appropriate Channel Resource for a given Web resource can be
discovered either passively or actively. Discovery is OPTIONAL; some
deployments may require out-of-band discovery, which is out of scope
for this document.
2.1.1 Active Discovery
Active discovery is accomplished by performing a WATCH on the Web
resource.
Nottingham Expires August 22, 2002 [Page 5]
Internet-Draft WARM February 2002
For example:
(request)
WATCH http://www.example.org/image.png
(response)
302 Found
Location: http://www.example.org/channel;A
Here, the location of the appropriate Channel Resource is found by
examining the target of the redirect. The semantics of HTTP status
codes in responses to active discovery requests should be honored as
they are defined in the HTTP.
The Resource SHOULD be considered associated with the actively
discovered Channel Resource until a subsequent WATCH changes the
association, or the semantics of the Channel Resource's
representation explicitly change the association.
2.1.2 Passive Discovery
Clients can passively discover Channel Resources by looking for the
Channel HTTP response header;
(request)
GET http://www.example.org/image.png
(response)
200 OK
Channel: http://www.example.org/channel;A
...
The Resource SHOULD be considered associated with the passively
discovered Channel Resource until subsequent representation has a
different or missing Channel response header, or the semantics of a
representation of the Channel Resource explicitly change the
association.
[[[ what about changes to the Channel Resource's state? ]]]
2.2 Monitoring
Once the appropriate Channel Resource is discovered, its state can be
monitored through the use of one of two techniques; subscription-
based monitoring and polling-based monitoring.
Subscription-based monitoring allows notifications to be sent as
quickly as network and other resource limitations allow them to be,
Nottingham Expires August 22, 2002 [Page 6]
Internet-Draft WARM February 2002
in combination with a heartbeat mechanism to assure that the channel
remains available.
Polling-based monitoring can be used in situations where the Channel
Resource is unwilling to maintain state about subscriptions, or where
network conditions (e.g., a firewall) make it impractical to expose a
Subscription Resource.
2.2.1 Subscription-Based Monitoring
Clients who wish to use subscription-based monitoring advertise this
through use of the Subscription HTTP request header, in combination
with the WATCH method. For example;
(request)
WATCH http://www.example.com/channel;A
Subscription: http://client.example.net/subscription;1
Accept: text/xml, */*;q=0.0
(response)
200 OK
A Channel Resourse SHOULD NOT return a successful status code to the
WATCH method until it has initiated the Subscription Resource (with a
PUT). If it cannot do so, it SHOULD return an appropriate client or
server failure status code. In disconnected deployments, it MAY
return 202 Accepted.
In subscription-based monitoring, the Channel Resource must first
initialise the state of the Subscription Resource by PUTing a
representation of the channel into it. Thereafter, the Channel
Resource may update the state of the Subscription Resource with
subsequent PUTs, and forceably delete the subscription with DELETE.
Integrity of channel connectivity is assured by polling the
Subscription Resource with the POST method and an empty entity body.
For example;
Nottingham Expires August 22, 2002 [Page 7]
Internet-Draft WARM February 2002
(initialise/update request)
PUT http://client.example.net/subscription;1
Cache-Control: max-age=600
Content-Type: text/xml
[entity body]
(initialise response)
201 Created
(update response)
200 OK
(heartbeat request)
POST http://client.example.net/subscription;1
Cache-Control: max-age=600
Content-Length: 0
(heartbeat response)
204 No Content
(delete request)
DELETE http://client.example.net/subscription;1
(delete response)
200 OK
PUT and POST requests to Subscription Resources SHOULD include a
Cache-Control: max-age header. Its value is used to determine when
the next heartbeat should arrive by; if a heartbeat is not received
by its expiry, the Subscription Resource SHOULD be considered
deleted.
[[[ is this a good use of Cache-Control, or would it be more correct
to define a new header? ]]]
The semantics of HTTP status codes in responses MUST be honored. In
particular, if any request to a Subscription Resource returns 410
Gone, the Channel Resource SHOULD consider the subscription canceled,
and cease monitoring.
2.2.2 Polling-Based Monitoring
Clients using polling-based monitoring make periodic HTTP requests to
the Channel Resource; the response represents its current state.
To ensure correctness and efficiency in polling-based monitoring,
Nottingham Expires August 22, 2002 [Page 8]
Internet-Draft WARM February 2002
Channel Resources MUST support ETag validation. Channel Resources
SHOULD use the Cache-Control response header for GETs to declare how
long that representation of the channel should be considered fresh
(and therefore, how long before the client should poll again).
For example;
(request)
GET http://www.example.com/channel;A
If-None-Match: "abcde"
Accept: text/xml, */*;q=0.0
(response)
304 Not Modified
Cache-Control: max-age=600
ETag: "abcde"
3. Relationships to Network Nodes
Because they are located by URIs, Channel and Subscription Resources
may be located on any addressable network node. However, it may be
helpful to illustrate a typical implementation;
+--------+ +--------+
| | ------ request(s) to Channel Resource(s) -----> | |
| HTTP | | HTTP |
| Client | | Server |
| + | <--- request(s) to Subscription Resource(s) --- | + + |
+--------+ +--------+
^ ^ ^
\ Subscription Resource Channel Resource / |
Web Resource /
This illustration should not be construed to limit the location of a
Channel Resource to the network node on which the resource(s) it
characterizes reside, or to prohibit the location of a Subscription
Resource on a node other than the HTTP client. Indeed, there are
many scenarios where it is beneficial to do so, for purposes of
scalability, managability, assertion of administrative control, or
for disconnected operation.
4. Using WARM for Cache Invalidation
WARM may be used to maintain coherence of cached representations. In
this application, the payload of notifications is a simple XML
document identified by the application/xml media type, using a single
element, 'cache', in the WARM cache namespace;
Nottingham Expires August 22, 2002 [Page 9]
Internet-Draft WARM February 2002
<?xml version="1.0"?>
<cache xmlns="http://www.intermediaries.org/warm/1.0/cache">
abcdefg
</cache>
The content of the element is a nonce generated by the Channel
Resource to identify its current revision level; it MUST be
guaranteed by the Channel Resource to be unique in its scope. When
any Web resource associated with the Channel Resource becomes stale,
the Channel Resource state SHOULD change.
This implies that the cache will track the mapping between Web
resources and Channel Resources and/or Subscription Resources, so
that when notifications are received, the appropriate representations
can be marked stale. Web resources that are associated with such
WARM Channel Resources SHOULD be considered fresh until such a
notification is received, the channel is deleted, or connectivity is
lost.
WARM can also be used with other cache-related payloads; their
semantics, interactions with cache behaviour, and additional
association mechanisms are format-dependent.
For purposes of content negotiation, the media type of this format is
"[[[ TBD ]]]".
5. IANA Considerations
5.1 The WATCH HTTP request method
The WATCH method is used to associate a Subscription Resource with a
Channel Resource, or to locate an appropriate Channel Resource. If a
Subscription Resource is associated, regular requests containing
heartbeat and/or update messages (as described above) will be made to
it.
watch = "WATCH"
WATCHing a resource may instigate one or more requests to
subscription resources, if subscription-based monitoring is in use
(as evidenced by a Subscription request header). If content
negotiation is used to determine the representation sent in response
to the WATCH, the same representation SHOULD be sent in subsequent
PUTs to the Subscription Resource.
Implementations SHOULD interpret HTTP status codes resulting from
WATCH as defined in RFC2616. Web resources that are not Channel
Resources MAY return 303 See Other to direct clients to the
Nottingham Expires August 22, 2002 [Page 10]
Internet-Draft WARM February 2002
appropriate Channel Resource, which may then be monitored by polling
or subscription.
WATCH requests MAY contain an entity-body; however, this document
does not specify a format for them.
5.2 The Subscription HTTP request header
The Subscription request header is used to indicate the URI of the
Subscription Resource that the client wishes to associate with a
Channel Resource.
subscription = "Subscription" ":" URI
5.3 The Channel HTTP response header
The Channel response header is used to indicate the URI of the
Channel Resource associated with the Web resource.
channel = "Channel" ":" URI
6. Security Considerations
WARM uses the same confidentiality, integrity, authorization and
authentication as HTTP does. Therefore, the use of SSL/TLS, the
Content-MD5 header and HTTP authentication mechanisms are
encouraged, and support for them in implementations is
RECOMMENDED. Such issues are relevent to both Channel Resources
and Subscription Resources.
WARM allows Channel Resources to make statements about Web
resources in other administrative domains. Client implementations
SHOULD be aware of the impliations of this, and be conservative in
their trust of such statements.
Certain modes in WARM imply non-trivial resource use by either the
client or the server; implementations SHOULD limit their use
through techniques such as increasing the lifetime of
representations (through the Cache-Control header), limiting the
number of clients accepted, etc.
References
[1] Fielding, R., "Architectural Styles and the Design of Network-
based Software Architectures", 2000, <http://www.ebuilt.com/
fielding/pubs/dissertation/top.htm>.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Nottingham Expires August 22, 2002 [Page 11]
Internet-Draft WARM February 2002
Levels", RFC 2119, March 1997.
Author's Address
Mark Nottingham
EMail: mnot@pobox.com
URI: http://www.mnot.net/
Appendix A. Acknowledgements
The author would like to thank Paul Prescod for the spark that led to
WARM, Roy Fielding for his description of the REST architectural
style [1] that it is built upon, Mark Baker for his insight and
patience in explaining and applying REST, and Rohit Khare and Adam
Rifkin for their overview of Internet-Scale Event Notification
Services.
Any error, misconception or bad design in this document is the
responsibility of the author, not them.
Appendix B. Issues/TODO
o Discuss WARM Intermediaries, to scale to large deployments.
o Formalize the cache and state models.
o how does a client specify authentication credentials for the
Subscrition Resource?
Nottingham Expires August 22, 2002 [Page 12]
Internet-Draft WARM February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nottingham Expires August 22, 2002 [Page 13]