The simple fact is that "convergence" layer protocols, that allow one
protocol to work on top of another, are separate specification efforts
from
either of the protocols being converged. It is not automatically
better to
have the "top" or the "bottom" layer originating standards group do the
convergence protocol.
Meeting the needs of the top layer is imo best understood by the
top-layer group, which works within the framework already established
by the bottom-layer group. That way you may well end up with something
sucky, but at least it should be adequate to the needs of the top
layer.
That's exactly the logic that has led to bad protocol designs so many
times in the past.
There are bad protocol designs and there are good protocol designs.
Many are produced using similar methodologies; it's hardly the only
defining factor.
Actually, in many cases it *is* the defining factor. Frameworks are fine as far
as they go but they just don't provide enough guidance to get things right in
many cases. And the assumption that they do often leads to trouble.
care to give specific examples?
There are so many it is difficult to know where to begin. Here are two that
continue to plague us to this day.
The poor use of TCP by HTTP almost certainly could have been addressed had HTTP
been designed with more input from transport layer folks.
The design of MIME failed to take certain security issues into account and as a
result makes end to end security more of a pain than it should be. And I know
for a fact this was a direct result of security and application working
group scheduling conflicts -- I was there.
Ned