2.1.15 Web Intermediaries (webi)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


Ian Cooper <icooper@equinix.com>
Mark Nottingham <mnot@akamai.com>

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

General Discussion:webi@equinix.com
To Subscribe: webi-request@equinix.com
In Body: (un)subscribe
Archive: http://www.wrec.org/webi-archive/

Description of Working Group:

This working group addresses issues specific to intermediaries in the World Wide Web infrastructure, providing generic mechanisms which are useful in several application domains (proxies operated by access providers, content delivery surrogates, etc).

Intermediaries are commonly deployed to help scale the WWW. Lack of mechanisms to control and communicate with them brings about scalability issues with intermediaries themselves, and lack of strong, scalable coherence mechanisms limits their adoption by both end users and content publishers.

Furthermore, access providers who wish to provision caching proxies in their networks have no standardized mechanism to announce such devices to user agents. As a result, many access providers resort to the use of interception proxies, which break the end-to-end relationship between client and server at the transport layer, leading to undesired behaviors.

Accordingly, the group's work items are to:

1) Develop a resource update protocol.

2) Gather requirements for an intermediary discovery and description mechanism.

It is expected that after requirements for intermediary discovery and description are gathered and evaluated, the working group will re-charter to continue that work.

Issues pertaining to coordination between multiple administrative domains are explicitly out of scope in this group's work items. Work associated with the modification of messages by intermediaries is also out of scope. Additionally, this group will only address application-level (e.g., HTTP) intermediaries.

Goals and Milestones:

Feb 01


Submit Requirements for Resource Update Protocol as an Interne Draft

Mar 01


Meet at Minneapolis IETF

Jul 01


Submit Requirements for Intermediary Discovery and Description as an Internet-Draft

Aug 01


Meet at London IETF

Nov 01


Submit Resource Update Protocol as an Internet Draft

Dec 01


Meet at Salt Lake City IETF

Feb 02


Submit Resource Update Protocol to the IESG for consideration as standards-track publication

No Request For Comments

Current Meeting Report

Minutes of the WEBI Working Group meeting, IETF51 (London)
Tuesday, 7 August 2001; 1300-1400

Ian Cooper (icooper@equinix.com)
Mark Nottingham (mnot@akamai.com)

The primary purpose of this meeting is to bring the RUP Requirements document to a state where it can move forward to WG Last Call.

1) Agenda Bashing 2 minutes
2) Group Status 3 minutes
3) draft-ietf-webi-rup-requirements-01.txt 50 minutes
4) IDD update 3 minutes
5) Wrap up 2 minutes

Minutes taken by:
Ian Cooper (icooper@equinix.com)
Imran Chaudhri (imran@panteratech.com)

Minutes combined by Ian Cooper

During agenda bashing a request to cover ESI (Edge Side Includes) Invalidation was made. Mark Nottingham stated that he had already planned on giving an update and that this would be given in the context of the RUP requirements update. Agenda accepted.

The chairs aired their concerns over a feeling of past lack of participation, but acknowledged that there had been good discussion on the mailing list. Thanks was given to Dan Li for her work on the RUP requirements draft. Less than half of the room acknowledged having read the requirements draft.

Mark Nottingham proceeded to cover some open issues in the RUP requirements draft.

Use Cases:
1) Server driven invalidation (push)
Oskar Batuner commented that the document in general was very protocol oriented and suggested that it should not go into some deep levels of discussion.

Oskar also commented that requirements should not necessarily concentrate on specific directions, but should support a general case - may be a hierarchical configuration where the (origin) server is not directly in communicating with the systems ultimately receiving the notifications.

(?)Joseph Hui suggested we should assume a reliable transport protocol - requiring positive acknowledgement could tie up the system.

2) Client driven invalidation (pull)
General feeling, raised by Oskar Batuner, was that the use case was good. Dirk-Willem van Gulik commented that it may make life easier with outward facing systems.

Fred Douglis commented that allowing arbitrary "clients" to participate in RUP was a good idea, but would complicate things.

Paul Gleichauf suggested we do not use the term "transaction" since it conveys strong meaning in other senses. The group agreed on this point.

?? suggested confirmation of (in)validation needs to be a requirement. Dave Martin stated that confirmation was a requirement.

Andrew Randall asked whether this was a use case for OPES. Lee Rafalow stated that this would be bending OPES, though it could be done.

For discussion on the list: should the systems be transactional?

3) Content location update
(This is where a content system redirects the receiving system to go elsewhere for the invalidations)

Lisa Amini commented that this crosses over from pure invalidation to meta-data, and that we would need to address meta-data in general if included. At present this use case is the only reference to meta-data. Mark Nottingham responded that he believed we should have meta-data signalling but that list traffic indicated it was too much to cover for the first draft and that we should be concentrating on invalidation in this version. Lisa and John Border commented that CDI needs meta-data; we should avoid duplication between groups where we can.

Mark Nottingham suggested we address invalidation (as the primary payload) at present but to allow other data to be distributed while not considering the exact definition of those payloads at this time.

4) Content prefetch hint
Ian Cooper made a general comment within the context of this case that the terms "client" and "server" appear to be confusing within the document since they have well defined uses as roles in other environments. Some possible suggestions were made:

??: "invalidator" for client, "listener" for server

Imran Chaudhri: content viewer and content publisher

Paul Gleichauf suggested we examine references in the distributed processing realm for assistance here.

Also queried regarding "managed" and "unmanaged" entities (e.g. cache) and whether better terms could be found. Andrew Randall queried whether we needed to make any distinction between managed and unmanaged entities in any case - group consensus was that there was no need to make this distinction.

Mark Nottingham commented that the document needs to include a list of those entities that are allowed to participate within the RUP protocol realm.

(Aside comment from Mark Day - the group needs to maintain an "issues list". Some discussion as to whether this was the responsibility of the chairs ensued (no firm outcome).)

Ian Cooper queried whether there was any way to limit the scope of use of the protocol (in order to address scaling characteristics) other than authorization. Oskar Batuner suggested that an authorization feature was required to limit access. Fred Douglis commented that some systems explicitly deny access from browsers. Joseph Hui commented that we should examine AAA requirements.

At this point it was noted we were starting to run short on time and that discussions should be moved to the mailing list.

Mark Nottingham gave a short updated on the ESI invalidation protocol - originating at Oracle. Moves toward this being a SOAP based protocol. ESI Invalidation is a point-to-point solution of limited utility whereas RUP is intended as a scalable protocol. Lee Rafalow queried where a point-to-point protocol would be more appropriate than a scalable protocol. Fred Douglis commented that point-to-point had first mover advantage. Mark stated that he would write an email explaining the issues and would send these to the list.

A short update on IDD was given; the co-chairs had had no success in generating any interest in the browser vendor community, although IDD was still seen as interesting. The chairs encouraged contributions in this area.


None received.