URI Update Protocol would end up being "You up?", a common enough
protocol message in this arena.
For the irony impaired, I'm joking.
Ted
>
>
> Agree; I think that this can and should evolve into a general mechanism for
> propagating messages from the origin to intermediaries.
>
> I'd say the general characteristics of what we're chasing (straw man) are:
>
> * intermediary (client) registers interest in resource(s) with a server (can
> be, but doesn't have to be, the origin)
>
> * once registered, message flow is predominantly server->client, initiated
> by server
>
> * message payload can be invalidations, object metadata/handling
> instructions, deltas, etc. (don't know if log pushing is in scope)
>
> So, 'U' for update is more accurate, if we go this way. One might also say
> that 'C' for cache is a bit restrictive/misleading; How about Web
> Intermediary Update Protocol -- WIUP?
>
> I like 'W' for Web, as Web is > HTTP; it denotes that the protocol can
> update anything with a URI.
>
>
>
>
> On Wed, Nov 22, 2000 at 06:31:39AM -0800, Dan Li wrote:
> > Given that this protocol specifies a notification transport (channels,
> > relays, aggregations, etc.) and various notifications (invalidation,
> > updates, preloads, log report, etc.) on top of it, the word "invalidation"
> > seems less than descriptive as in WCIP.
> >
> > Along this line, it sounds to me that something like WCUP "web cache update
> > protocol" would be better. If the name WCIP is over restrictive and we may
> > need to change it sooner or later, I'd say we change it now. Do you feel
> > the need?
> >
> > Dan
> >
> > > > >>> Dan Li <lidan@cisco.com> 11/15/00 01:57PM >>>
> > > >Hi, please take a look of the WCIP draft before the IETF meeting, as we'd
> > > >spend time on issue discussions and won't cover the draft in detail. This
> > > >draft is a strawman, at least the following things need more work:
> > > >
> > > >- clearly define the relationship of wcip with normal cache-control
> > > >directives.
> > > >
> > > >- specify in more detail the role of relay point, especially for channel
> > > >aggregation. Can we or can we not aggregate heartbeats, possibly but
> > > >cutting freshness guarantee.
> > > >
> > > >- pick a security model. Use SSL, or PGP signature, or both, and also the
> > > >security of the channel info.
> > > >
> > > >- do we need a default port number? pros and cons wrt. to port 80.
> > > >
> > > >- are people happy with persistent TCP connection? are people happy with
> > > >"delta consistency" (vs. eventual consistency, strong consistency, or
> > > >anything else).
> > > >
> > > >- in the absence of a off-the-shelf realtime reliable multicast protocol,
> > > >can we still run wcip on multicast UDP for scalability. See section 3.2.3.
> > > >
> > > >- preloading, log reporting, advanced event notification, programability,
> > > >.. future stuff on vertical peering and dynamic content
> > > >
> > > >What do people think?
> > > >
> > > >Dan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >At 08:12 AM 11/15/00 -0800, Ian Cooper wrote:
> > > >
> > > > >>To: IETF-Announce: ;
> > > > >>From: Internet-Drafts@ietf.org
> > > > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt
> > > > >>Date: Wed, 15 Nov 2000 06:41:12 -0500
> > > > >>
> > > > >>A New Internet-Draft is available from the on-line Internet-Drafts
> > > > >>directories.
> > > > >>
> > > > >>
> > > > >> Title : WCIP: Web Cache Invalidation Protocol
> > > > >> Author(s) : D. Li, P. Cao, M. Dahlin
> > > > >> Filename : draft-danli-wrec-wcip-00.txt
> > > > >> Pages : 26
> > > > >> Date : 14-Nov-00
> > > > >>
> > > > >>Cache consistency is a major impediment to scalable content
> > > > >>delivery. This document describes the Web Cache Invalidation
> > > > >>Protocol (WCIP) which uses invalidations and updates to keep
> > > > >>changing objects up to date in web caches. Moreover, it allows
> > > > >>automatic one-to-may relay and many-to-one aggregation in a CDN
> > > > >>(content delivery network) environment.
> > > > >>
> > > > >>A URL for this Internet-Draft is:
> > > > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt
> > > > >>
> > > > >>Internet-Drafts are also available by anonymous FTP. Login with the
> > > > username
> > > > >>"anonymous" and a password of your e-mail address. After logging in,
> > > > >>type "cd internet-drafts" and then
> > > > >> "get draft-danli-wrec-wcip-00.txt".
> > > > >>
> > > > >>A list of Internet-Drafts directories can be found in
> > > > >>http://www.ietf.org/shadow.html
> > > > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >>
> > > > >>
> > > > >>Internet-Drafts can also be obtained by e-mail.
> > > > >>
> > > > >>Send a message to:
> > > > >> mailserv@ietf.org.
> > > > >>In the body type:
> > > > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt".
> > > > >>
> > > > >>NOTE: The mail server at ietf.org can return the document in
> > > > >> MIME-encoded form by using the "mpack" utility. To use this
> > > > >> feature, insert the command "ENCODING mime" before the "FILE"
> > > > >> command. To decode the response(s), you will need "munpack" or
> > > > >> a MIME-compliant mail reader. Different MIME-compliant mail
> > > > readers
> > > > >> exhibit different behavior, especially when dealing with
> > > > >> "multipart" MIME messages (i.e. documents which have been split
> > > > >> up into multiple messages), so check your local documentation on
> > > > >> how to manipulate these messages.
> > > > >>
> > > > >>
> > > > >>Below is the data which will enable a MIME compliant mail reader
> > > > >>implementation to automatically retrieve the ASCII version of the
> > > > >>Internet-Draft.
> > > > >>
> > > > >>Content-Type: text/plain
> > > > >>Content-ID: <20001114131241.I-D@ietf.org>
> > > > >>
> > > > >>ENCODING mime
> > > > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt
> > > > >>
> > > > >><ftp://ftp.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt>
> > > > >
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA)
>
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST