Subject: Re: WREC/CDNP/extproxy ... moving forward

From: Michael Condry <[email-masked]>
Date: Wed, 11 Oct 2000 09:49:40 -0700 (PDT)

> X-URI: http://www.cs.utk.edu/~moore/
> To: Oliver Spatscheck <[email-masked]>
> cc: Keith Moore <[email-masked]>, Ian Cooper <[email-masked]>, LOVRIC 
Ivan FTRD/DMI/CAE <[email-masked]>, [email-masked]
> Subject: Re: WREC/CDNP/extproxy ... moving forward 
> List-Unsubscribe: <mailto:[email-masked]?Subject=unsubscribe>
> 
> > now every player on the Internet has some kind of responsibility to the 
> > consumer or the content-provider.
> 
> right, but at some point that responsibility is so distant that it 
> is no help in fixing things when they don't work. 

I am not sure I agree. That is the way things work today.
This is the additional architecture we need to add.
 
> 
> or to put it another way, we should design the system in such a way that 
> (at least, for components that conform to the specification)
> the behavior of intermedaries is specified by the end-users of the system
> (meaning both providers and consumers) and such intermediaries can 
> be circumvented when the need arieses.
> 
> Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Oct 2000 13:10:15 -0400

> This is the additional architecture we need to add.

I'm not sure what you're trying to say here.

as far as I can tell, things mostly work today in the absence of
intermediaries, and they fail quite often in the presence of 
intermediaries that filter and/or alter content.    in the cases
where the intermediaries cause failures, it's often difficult to
fix the problem because the intermediary cannot be controlled.
(often it's not even identified as the culprit)

this is at every level of the protocol stack.

Keith

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 12 Oct 2000 00:55:24 +0200

I would like people to differ in the discussions between:

  - What issues are there to talk about
  - What issues are good/bad/inside IETF/outside IETF

I don't mind having things on the list which we later find that IETF 
should not deal with because of various reasons. A list of "this wg 
should NOT deal with the following things" is sometimes better than 
one only talking about things which are included.

That said, I never saw a list with issues which people agreed on...

     Patrik