Subject: Fwd: Re: Proposed charter

From: Ian Cooper <[email-masked]>
Date: Mon, 15 Jan 2001 16:07:55 +0000

>From: Scott Brim <[email-masked]>
>Date: Fri, 12 Jan 2001 14:09:40 -0500
>To: Mark Nottingham <[email-masked]>
>Cc: [email-masked]
>Subject: Re: Proposed charter
>X-Mailer: VM 6.89 under Emacs 20.7.1
>Sender: [email-masked]
>
>Just one question ...
>
>On 11 Jan 2001 at 18:16 -0800, Mark Nottingham apparently wrote:
> > 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.
>
>Could we possibly back up one step and treat channel mechanisms as a
>possible solution instead of a given?  I mean, let's start with the real
>requirements.  If you believe channels have already been justified
>somewhere, could you point me to that RFC?  Channels imply basic
>assumptions about how intermediaries relate to their content sources.
>
>...Scott

---

From: Ian Cooper <[email-masked]>
Date: Mon, 15 Jan 2001 16:07:33 +0000

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 
"[email-masked]".  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 <[email-masked]>
>To: [email-masked]
>Subject: Proposed charter
>User-Agent: Mutt/1.2.5i
>Everyone, please have a look over this and give feedback,
>particularly on the schedule.
>
>Cheers,
>
>
>---8<---
>
>Web Intermediaries (webi)
>
>Chair(s):
>     Mark Nottingham <[email-masked]>
>     Ian Cooper <[email-masked]>
>
>Applications Area Director(s):
>     Ned Freed <[email-masked]>
>     Patrik Faltstrom <[email-masked]>
>
>Applications Area Advisor:
>     Patrik Faltstrom <[email-masked]>
>
>Mailing List:
>     General Discussion: [email-masked]
>     To Subscribe: [email-masked]
>     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:
>
>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)

---

From: Ian Cooper <[email-masked]>
Date: Mon, 15 Jan 2001 16:08:07 +0000

>Date: Fri, 12 Jan 2001 11:27:56 -0800
>To: Scott Brim <[email-masked]>
>Very valid point.
>I'll take this as a suggestion to strip out the two sections
>detailing the approaches to the work items, and reduce them to
>bare-bones work items (letting the motivation above put a general
>scope on the problem). If anyone has a suggestion for more
>substantial content here that doesn't presuppose the requirements too
>much, please send something ASAP.
>
>The only catch is that I don't know if we can roadmap the delivery of
>anything past the requirements doc if we don't have an understanding
>of what needs to be delivered.
>
>Also, note that the names for the work items are tentative - they're
>just there so we have something to refer to. I imagine that we'll
>finialize those once we get the requirements solidified.
>
>Cheers,
>
>
>
>
>On Fri, Jan 12, 2001 at 02:09:40PM -0500, Scott Brim wrote:
> > Just one question ...
> >