2.1.10 Web Replication and Caching (wrec)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 24-Jun-99


John Martin <martin@terena.nl>
Bill Maggs <billm@mci.net>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:wrec@cs.utk.edu
To Subscribe: wrec-request@cs.utk.edu
Archive: ftp://cs.utk.edu/pub/wrec

Description of Working Group:

The purpose of this working group is to define a co-ordinated caching and replication framework for the world wide web.

Replication of web services and caching of http responses are distinct paradigms that to a large degree require distinct solutions. However, it is also important that web caches and replicated services be able to coexist. Ultimately, the working group will define a framework for efficient, reliable, and predictable service in a web which includes both replicas and caches. Part of this framework will be a means by which replicas and caches may be automatically discovered and utilized by clients.

Because of the wide variety of caching and replication solutions which are already in use, the initial task of the group is to familiarize itself with the diversity of existing practice. The group will therefore produce a document which provides a taxonomy of existing caching / replication developments and terminology which would be used as a reference for later work. In parallel with this, existing protocols and standards which are not publicly documented will be submitted to the IESG for publication as informational RFCs by their respective proponents. Once the initial phase is complete, the group will make a recommendation as to whether further protocol work is necessary or desirable, and submit a revised charter for consideration by IESG and IAB.

Goals and Milestones:

Mar 99


First issue of I-D on taxonomy and terminology (Editor: I. Melve)

Mar 99


First issue of I-Ds on existing caching / replication protocols

Mar 99


Meet at Minneapolis IETF

Apr 99


First issue of I-D on design goals / research issues (Editor: J. Touch)

Apr 99


Final issues of I-Ds on existing caching / replication protocols

Jun 99


Final issue of I-D on taxonomy and terminology

Jun 99


Final issue of I-D on design goals / 688 research issues

Jul 99


Meet at Oslo IETF

Jul 99


Submit I-Ds to IESG for publication as Informational RFCs

Jul 99


Revise charter


No Request For Comments

Current Meeting Report

WREC Working Group Minutes

These are the minutes from the Web Replication and Caching (wrec) working group meeting at the 45th IETF meeting in Oslo, Norway on 12 July 1999. These minutes are available on the web at http://www.hpl.hp.com/personal/John_Dilley/ietf-45-wrec-minutes.html.

WREC Taxonomy Document - Ingrid Melve

Ingrid presented the current status of the Web Replication and Caching Taxonomy working draft, draft-ietf-wrec-taxonomy-01.txt, and asked the attendees for input on a number of remaining open issues. This section captures highlights from the presentation, summarizing the slide presentation.

Taxonomy Draft

Points here: assume you have read the draft. The main issues are security, terminology, and "transparent". The team is aiming for a final version "real soon now".

Security, Non-issues

Non-issues related to security include system security and HTTP; the draft is not doing anything about these, take them as they are. The underlying security issues are taken as a baseline for web cache security.

Security Issues

The main security issues for web caching were discussed. At present these are


- Network element: something which introduces multiple paths between source and destination, transparent to HTTP

- Joe Touch will send mail on spatial, temporal, and ensemble domains.

How should terminology be described in the document?


Suggestion: always preface the term transparent with an adjective, such as "semantic", "network", "user", "automatic configuration". Define these terms. Transparency is dependent upon the layer you are working at. HTTP/1.1 working group has also fought with this.

Need to distinguish between browser configuration and network transparency. Avoid use of transparency for browser configuration -- call that automatic browser configuration.

Next draft to be available by 1st September 1999 for presentation to the wrec@cs.utk.edu mailing list. Goal: get closure via the mailing list before the Washington IETF meeting.

Inter-Cache - Ian Cooper

The Inter-Cache effort is working out protocol modifications in ICP and HTCP to improve how caches communicate. Three changes have been agreed to in the last six months, and are in the process of being implemented. The next document revision will correct some remaining minor problems and will be submitted as an Internet Draft. The three changes are:

Via Header Mods

Add product-name and product-version, add tracecode and trace-time. See the working draft for details.

Comment: you might want to carry this information for events other than a hit or a miss, for example access denied or for caches to exchange product name and version information.

Question: what is trace time? Trace time is the time the object was last verified by the proxy. Need for multiple trace times since each proxy in the chain can validate at a different time; trace time is different from last-modified time.

PURGE Method

Two purge operations are proposed for ICP and HTTP:

Should have an implementation note so proxies will err on the side of conservatism and : keep these PURGE methods from going too far.

Question: the threat model is obvious. What is the security model?

Remove URL from ICP Replies

New ICP flag; if present in a request, response must include the flag and should not send the URL in payload. Standard RFC2168 response if flag is not present in a request - products should be careful to follow the spec.

Recommend to make this an informational RFC.

Point from the floor: documents must be standards track to add a new method to HTTP/1.1 standard. Is this planned?

Known Problems Draft - John Dilley

Document Purpose: Document the state of content caching protocols and products on the web today.

Known Problems - Summary of current submissions made; see the draft for details.

Next Steps

Brian Carpenter: Status of WPAD: is it really a solution to a known problem? Is it a proprietary technology? May not be relevant to this document. Company submittals are OK but are different from (IETF) standard solutions.

Joe Touch: Difference between performance issues and known problems. Know problems break the spec, cause catastrophic problems for conformant products. "Not as good as we want it to be" is another issue. Do we want to capture those in this document? General feeling was yes, we did, although the serious problems should be separated from the performance issues.

Other Business - WREC Chairs

Version 2 of WCCP v1 has been submitted for publication. It was not presented at the meeting. A new version of the WPAD draft has also been submitted. It is implemented in ie5. It was not presented either.

Publishing RFCs as Informational or Standard - Informational is acceptable for proprietary protocols and are useful so specifications are freely available from ietf.org. Standards track RFCs require multiple independent implementations and open, community-influenced specifications.

John Dilley briefly introduced a potential alternative for inter-cache communication based upon a distributed object consistency protocol. An introductory white paper will be posted to the wrec mailing list for discussion and input.

Rechartering: John Martin mentioned the desire to re-charter the group to be able to address broader topics, but noted that we need further progress on current work before rechartering the working group.


None received.