That is going to become a philosophic discussion about engineering goals ;-)
While my experiences as a software engineer contain always compromises and
never included the theoretical best solution, it still has always been the
goal to create the best under the given circumstances (usually means:
having limited resources).
Especially creating a protocol means to me to do something more than the
absolute minimum, because others should benefit from it, now and in some
future. And all upcoming users do also have their restrictions.
So forcing those to implement a lot of new code, maybe including support
of other libraries, which are only needed because this group wanted to
have a minimum of work - that's a way I have question marks with whether
OCP can be successful.
But should the consensus be that the WG should just meet the minimum
charted goals, then we should just update ICAP and create ICAP/1.1 which
simply addresses the few open issues.
[Even being the ICAP guy here, this is not my preferred way.]
Martin
[ speaking as the beep guy, final message... ]
where i interested in seeing this work complete, i would be
leveraging every existing open standards thing i could
get my hands
on. i wouldn't care at all about optimality. i would care about
getting the job done before the IESG wises up and figures out that
this working group isn't going to succeed.
Why are you not suggesting that we simply use ICAP/1.0 as OCP, then?
ICAP/1.0 (RFC 3507) exists, works, and is open.
and if it meets all the requirements (including stuff like
security) and
can pass iesg muster, then that's what the working group should use.
Personally, I think that it is far better for this group to
be forced
to close by the wise IESG than to produce OPES protocols
that are not
much better than the existing ones. It is better to produce nothing
[new] than to just further dilute protocol set for OPES-like things.
We have to build the "best" OPES protocols to justify this WG
existence.
i have yet to attend an engineering meeting where the goal is the
"best". the goal is never the "best". the goal is to get things right
enough, cheap enough, and fast enough to solve enough of the
problem and
then move on.
i have attended many research meetings, where the goal, as you might
expect is the "best".
fundamentally, i have to put the ietf and it's working groups into the
engineering category. others' mileage may, of course, vary.
/mtr