On Wed, 2005/04/20 (MDT), <info(_at_)utel(_dot_)net> wrote:
Thank you to Alex in reviving his draft to make believe this WG, on what
I consider the most important current step towards the future internet,
is still alive.
If you are talking about the OCP/HTTP draft, then it was adjusted at IESG
request to fix minor bugs and address a pending DISCUSS item. AFAIK, the
delay with publication of that draft was not under this WG control. We
had to wait for feedback from IESG, and did try to speed it up on several
occasions.
I am interested to know if people here consider that pursuing on OPES
this is way is worth consideration, or if there should be a complete
rebuild of the concept in a new achitectural frame.
I do not think there are fundamental flaws in the OPES architecture.
I would love to see more activity in the WG, but we need more market
players for that. As of now, the market thinks that ICAP is good enough
for HTTP and can be forced to work for SMTP. If major players do not
want to invest in a better solution that covers more protocols (and
investment is required to implement and deploy OCP and P), then it is up
to this WG to decide whether providing that better solution is worth
the trouble. It is an "If you build it, will they come?" question.
I went recently on the site of Noel Chiappa and found there some old
document of him about the true nature of the end to end concept,
pertinent remarks about RFC 1958 real meaning, I found of interest. I
also work on a Draft of architectural elements I think we need to
address the Multilingual Internet and the user centric approach of a
true distributed network the digital convergence calls for.
I suspect that whatever new architectural elements you design, OCP can
be easily adapted to work with them. There are very few
architectural-level assumptions behind OCP, and I suspect those
assumptions will hold in any reasonable architecture. OCP and P are
very generic/universal tools. They can be used for many things, in
many architectures. Thus, I do not think the debates about RFC 1958
"real meaning" or any "Internet NG" drafts would affect the usefullness
of this WG work.
Our problem is not the architecture, but the lack of industry motivation
to invest in a standard adaptation interface for communication protocols.
I wish we could go back to the time when ICAP was being designed, when
there was significant industry push for _a_ solution. It would be much
easier to deliver a much better solution back then...
Alex.