-------- Original Message --------
From: Brian E Carpenter [mailto:brc@xxxxxxxxxxxxxx]
The proper cure for the disease Keith names has been agreed upon
for years now: early cross-area expert review.
I fully agree.
The question is whether this necessarily works to the intended
effect.
I think that it has to be possible for a WG to solicit cross-area
review but after due consideration of the advice reject it.
For example lets take BEEP which is still nominally an IETF Draft
Standard even though at this point a rational evaluation of its
status would be to consider it HISTORIC or DEPRICATED*. BEEP is
simply not a player in the Web Services world where the only
platforms that are being discussed are SOAP or layering on raw HTTP.
You might want to reread RFC 2026. BEEP met and continues to meet the
requirements for Draft Standard. Draft Standard is a measure of
specification quality and protocol quality and implementor interest. It
is not a measure of market acceptance.
Also, I think you may have left out some part of your argument. You
cited this as an example of a WG rejecting cross-area review. Even if
the BEEP WG got external reviews claiming that SOAP was better, I hardly
think that an NIH argument from an external party is a good
justification on its face for abandoning an IETF effort. SOAP is rather
poorly designed, and using HTTP as a substrate for any kind of RPC
protocol is generally a pretty poor idea, technically. In general, the
fact that lots of people out there do stupid things is not a reason for
IETF to endorse that kind of stupidity.
So now lets imagine that someone brings a proposal to the IETF that
is layered on SOAP and the WS-* stack. Are they to be required to
rewrite it to support BEEP just because a few folk in the apps area
don't recognize reality?
Do you actually see such a requirement in an RFC? Or are you just
imagining it? There are indeed rules for normative references in IETF
specifications, but they don't preclude using SOAP or Web Services as
long as there are stable specifications that can be referenced.
There has to be room here for "Your proposal adds nothing of value to
our project and will only harm it".
People are certainly free to make such claims and have them evaluated.
Of course it helps to have sound technical justification to back up
those claims.
In particular I think we really need to squash the mindset that goes
"I do not have to think about how to persuade people to deploy my
protocol because I can attach it to other protocols that people
actually want to deploy".
Marketing is certainly something that we could do better.
BEEP is a case in point. It was rushed through in a few months so
that the IETF could claim it had peed on the Web Services area first.
or maybe because its proponents felt it was technically superior?
(which IMHO it is)
The authors did not attempt the type of broad outreach that the
proponents of SOAP engaged in.
Again, marketing is certainly something that we could do better. But
just because the market selected something different than IETF produced
does not mean that IETF was wrong to try to do something technically
better than SOAP. Not everything IETF does will be successful in the
market, but we should still try to do good technical work - else there
is no purpose for IETF.
If the authors had been forced to think about the problem of
evangelising their platform it might have been more successful.
Instead they rammed it through the IETF without any attempt at
consensus building in the application developer community then tried
to imply that IETF standards are expected to be based on BEEP, not
SOAP.
Sometimes a good way to get a technology to be used is to get it blessed
as a standard before its competitors. It's not as if that approach
never works.
This is particularly important in the security area and for any
protocol with security issues - in other words always. Not so long
ago we used to have a habit of insisting that everything work over
everything and that agnostic support for HTTP, SMTP, NNTP, MIME, PGP,
S/MIME.
I'm sure there were people who believed that, but I don't recall any
consensus to that effect in the last 15 years or so.
* There is actually a bug here in BCP 9. It should be possible to
change the status of a platform specification so that no future
standards track specifications are built on it without affecting the
status of existing standards. For example IPv4 hould at this point be
considered DEPRICATED since all new standards proposals are required
to support IPv6.
That's ridiculous since it's still acceptable for new standards to
support IPv4 (thus requiring a normative reference to IPv4 or something
that uses IPv4) in addition to IPv6.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf