I thought it might be useful for me to forward a few articles from the webi
list here. I'd like to try and keep discussion on one list (webi) if at
all possible. To subscribe, send mail to
"webi-request@lists.equinix.com". We have a majordomo archive of all
traffic to date with a web version due soon. (There's also an unofficial
web archive at http://www.wrec.org/webi-archive/)
>Date: Thu, 11 Jan 2001 18:16:08 -0800
>From: Mark Nottingham <mnot@akamai.com>
>To: webi@lists.equinix.com
>Subject: Proposed charter
>User-Agent: Mutt/1.2.5i
>Sender: owner-webi@equinix.com
>
>
>Everyone, please have a look over this and give feedback,
>particularly on the schedule.
>
>Cheers,
>
>
>---8<---
>
>Web Intermediaries (webi)
>
>Chair(s):
> Mark Nottingham <mnot@akamai.com>
> Ian Cooper <icooper@equinix.com>
>
>Applications Area Director(s):
> Ned Freed <ned.freed@innosoft.com>
> Patrik Faltstrom <paf@cisco.com>
>
>Applications Area Advisor:
> Patrik Faltstrom <paf@cisco.com>
>
>Mailing List:
> General Discussion: webi@equinix.com
> To Subscribe: webi-request@equinix.com
> Archive: http://www.wrec.org/webi-archive/
>
>Description of Working Group:
>
>This working group will address 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 current work items are to:
>
>1) Gather requirements for, and specify, a Resource Update Protocol,
> consisting of:
>
> a) A framework containing:
>
> 1. A channel mechanism with associated channel advertisement,
> description subscription and reliability functions,
>
> 2. A message format for the channel payload, and
>
> 3. A scalable delivery model for messages.
>
> b) Specification of a Web Resource Invalidation Protocol as a
> payload for this framework, and optionally other appropriate
> payloads, as determined by the requirements.
>
>2) Gather requirements for an Intermediary Discovery and Description
> mechanism, consisting of:
>
> a) An intermediary description format, which describes what
> services an intermediary or arbitrary group of intermediaries
> is willing to provide, and
>
> b) A discovery protocol for locating relevant descriptions within a
> single administrative domain.
>
>Both requirements documents will provide a scope for their respective
>work items by enumerating previous and relevant work, providing
>design principles, functional requirements, requirements from other
>groups, and illustrative use cases.
>
>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.
>
>It is expected that after requirements for Intermediary Discovery
>and Description are gathered and evaluated in light of available
>resources and implementor interest, the working group will be
>re-chartered to continue that work if it is judged viable.
>
>Goals and Milestones:
>
>Feb 01: Submit Requirements for Resource Update Protocol as an Internet
> Draft
>Mar 01: Meet at Minneapolis IETF
>Jul 01: Submit Requirements for Intermediary Discovery and Description
> as an Internet-Draft
>Jul 01: Submit Resource Update Protocol Framework as an Internet Draft
>Aug 01: Meet at London IETF
>Nov 01: Submit Web Resource Invalidation Protocol as an Internet Draft
>Dec 01: Meet at Salt Lake City IETF
>Jan 02: Submit Resource Update Protocol Framework and Web Resource
> Invalidation Protocol to the IESG for consideration as
> standards-track publications
>
>---8<---
>
>
>--
>Mark Nottingham, Research Scientist
>Akamai Technologies (San Mateo, CA)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:30 MST