Ian,
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.
Agreed. We discussed this issue when writing the draft and decided to
go with "caching proxy" simply for conformance with the original draft
on extensible proxy services. I personally agree with you and believe
the term should be changed in both drafts, including the draft on
"Extensible Proxy Services". Internally, we always use the term "proxy
engine", because this component is really more than a "proxy" in the
traditional context. But if we want to move away from a web centric
view anyway, we should also move away from the term "proxy"...
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.
Agreed, and we might want to start thinking about that again (see
below).
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?
There are quite a view web based email clients out there (e.g.
hotmail, yahoo, etc.), for which a service like this would be helpful.
The draft should be more precise when talking about that.
(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 think the (current) draft does NOT discuss SMTP... Hm, maybe we
should include it and move away from the HTTP centric view on those
services. For example, a mail server could also act as an iCAP client,
forwarding received attachments for virus scanning, transformation
from text to speech, etc...
BTW, we've implemented a cache-enhanced mailing system that
demonstrates the usefullnes of caching even in he context of email -
but that's another story and should probably not be discussed here.
I'm not suggesting it's the best model, but one
possibility is simply to parse "comments" within the
HTML/XML.
That's basically what we meant with "The proxy could for instance scan
the Web page for a specific marking (e.g. a special tag)". A "special
tag" could be a special comment, for example. The drawback of this
"proprietary" solution is that it requires an agreement between the
content provider and the ad insertion service - both sites have to
agree on the "special comment", and an ad insertion service provider
would have to make this sort of agreement with every content provider
(and would have to provide a corresponding parser). This is where sort
of a "standard model/tag" would make sense.
Sections 6 and 7, in my mind, discuss very similar things.
They are similar, but NOT the same. Section 6 talks about adaptation
for different devices, while Section 7 talks about adaptation for
different bandwidths.
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).
Hm, *adding* content due to availability of additional bandwidth seems
to be much more difficult than *stripping* content. I can't see a
business model for that right now, but we migth include it for
completness.
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.
That would be great. I remember having heard about a project
implementing this kind of service somewhere at a University in
California, but unfortunately was not able to dig out a reference. If
somebody is aware of relevant projects, please let us know so that we
can reference them.
-Markus