At 04:57 PM 12/4/2000 -0800, you wrote:
Some general comments, hopefully constructive :) :
Throughout the document reference is made to caching proxies being used as
the platform on which services will be offered. While the majority of
such boxes deployed today probably do act primarily as content stores, and
they provide some obvious benefits where caching is practicable, there is
certainly no requirement for them to be *caching* proxies. (And one could
argue that caching, at even the simplest level, might be provided as a
service rather than as an intrinsic part of the platform.)
The original concept is a content driven device for services. Knowing
content, this
is a good device to direct actions with an associated cache, but it is not
the cache. You are correct, there is no requirement that these devices have
associated caches, but in many cases that does make sense.
In section 2 you introduce virus scanning in the context of email based
viruses, then move on to discuss scanning of Web pages and file
transfers. A couple of comments on this:
1) When some of the initial "extensible proxies" discussion took place
there was an idea that these devices might operate with the content on
more than one port, thereby enabling SMTP scanning, for example. I'm not
sure I see that any more.
2) In the absence of any reference to non-port-80 scanning, is it
sensible to introduce the subject in the context of email based viruses,
and then move on to the a Web centric view?
(and 3) if you're discussing something like SMTP caching, obviously
you want to depreciate the caching nature of the proxy, since it's not
going to be too beneficial in that case.)
I believe our focus was more on "content management" rather than type of
Internet service (email, web, etc.).
Section 3 discusses ad insertion. It's a business point, but the key
issue of localized ad insertion is the ability to 1) better target adverts
to end users (you have a much better understanding of where they are in
the network), and 2) to provide an additional revenue stream to the entity
whose boxes are doing the insertion (because they're closer to the
users). I'm also in some disagreement that a standard model for
identifying the ad space is required. It's the content providers content,
and they have deals with folks who know the size and types of ads that
should be inserted. I'm not suggesting it's the best model, but one
possibility is simply to parse "comments" within the HTML/XML. Part of
the problem with a well defined content (and therefore presumably stable)
structure is that it makes it inherently easy for ad-strippers to do their
work.
Yes, well defined content is a issue. As far as an "Ad Model" its not the
intent to
create one however, without some standards its not clear the rules to recognize
the suitable places. This is true particularly as the content becomes more
complex.
Sections 6 and 7, in my mind, discuss very similar things. And in fact,
section 7 doesn't consider the important aspect of bandwidth adaptation
where there's actually *more* bandwidth (where richer interaction could be
provided).
We disagree here. Transforming the content is different than telling the
network subsystem that a particular bandwidth is more useful for the
kind of content it is going to transmit.
Section 12 is rather interesting (for personal reasons). There are quite
a few academic references to this sort of work... I'll try to dig them out
and pass them along if that would be useful. For 12.3, one could possibly
use CIP (see RFC2651), perhaps.
Thanks.