Okay, so I'm very slow at getting involved in discussion I started. Getting
busy this morning, I'll try to play some catch up.
First in reply to Mark:
Although a CDN may be involved, they have a contractual relationship
with the content provider, and therefore represent the CP's
interests. There is little functional difference between a box
operated by Akamai or Mirror Image and distributed caches or mirrors
operated by the content provider.
I was going back and forth about including either the content provider,
hosting ISP and CDN as separate entities, but in the end I decided it was
better to have the extra blocks, for completeness sake if nothing else.
However, I can see a few extra features that would be supported that aren't
necessarily for content providers, particularly with the CDN.
First, they may support a feature for a single access provider or sub-group,
and the logistics of this would have to be addressed.
Next, they will surely have some plugins for their own use. Accounting
systems, resource allocation or perhaps CDI (CDNP? CDNI? whatever it is this
week) for example.
Also, by their nature a CDN will have an easier time introducing geographic
region information.
I'm still unsure about what the right thing to do here is. While it's
impossible to stop the deployment of 'processing intermediaries' by
access providers, I'm not thrilled about the encouragement of them.
Obviously, there are some legitimate functions that they provide -
such as caching (which might be thought of as a form of processing),
access control, etc. However, I get nervous when people start talking
about changing the messages themselves in-flight, without any
permission or control from either the end user or content provider.
I've seen some hand-waving about establishment of such mechanisms,
but not much more (pls correct me if I'm missing something).
I agree that this is something I don't entirely want to encourage, but the
truth is, it is being done now - content is being transformed for language,
display features and add insertion.
My thought is that if we can standardize how transformations are done, it
will be a lot easier to standardize how to stop transformations from
happening on particular content.
(However, in the end I'd bet if you want content in a non-transformable form
it will have to be something along the lines of the electronic book formats
that are being addressed, just for this reason.)
Separately, it's very difficult to require an intermediary to
implement whatever trust model we come up with; the HTTP is already
built, and retrofitting an intermediary trust model onto a protocol
which had to have intermediaries retrofitted into it is problematic,
to say the least.
I quite agree - in fact, I am not necessarily trying to set up an
intermediary. As with most things, I am hoping that the framework would
allow a model for an intermediary to fit in using OPES rules.
Ultimately, I'm concerned that the standardization of processing
intermediaries in the HTTP may restrict the usefulness of the Web,
rather than supplement it; application designers and users doing
things that the intermediary service designers didn't forsee will
have to deal with crossing an ill-defined boundry between the
"normal" web and the "adapted" web.
( If that doesn't get some discussion going, what will? ;)
Well, it certainly worked didn't it! Thanks for the feedback.
-Rob