At 21:18 12/4/2000 -0500, Markus Hofmann wrote:
Ian,
But if we want to move away from a web centric
view anyway, we should also move away from the term "proxy"...
Comments on the fact that we might be better off with "intermediaries"
aside, "proxy" shouldn't tie us to a web centric view, surely.
> 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.
But since you are modifying either the content providers content, or the
advertisement company's ads, you will have to have some kind of business
agreement with them. So I don't see that it's of particular concern
knowing "what to look for". The issue is perhaps the optimization of the
parser - if there's some kind of "standard" then the proxylets would likely
be more efficient. I'm still not sure that ad/content folks would want to
make it so easy for ad strippers to do their work though.
> 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.
Hmm, true, but the examples aren't particularly clear in that
respect. There's a lot of duplication that *suggests* they might be merged.
> 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.
At 20:19 12/4/2000 -0800, Michael W. Condry wrote:
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.
OK, I guess there could be a little bit of playing with the semantics of
"network subsystem", but would it not be useful for these devices to adapt
content in both directions? Why shouldn't the box be in a position to
signal, within HTTP for example, that the client is well connected and that
a higher bandwidth variant of a resource can be delivered?
In addition, the document suggests in section 5 the construction of
personalized pages from content components. It should be quite possible
for this sort of device to introduce richer content from its store (or by
introducing a signal within the inbound request) where that is
appropriate. One specific example, in the case of ad insertion, would be
to add a streaming media ad for someone on a broadband link.
I understand what you're saying Michael, but I'm not sure things are quite
as clear but in terms of what "content transformation" actually means.