The demand to use BEEP was real. Since the purpose of a middleware layer like beep is to provide uniformity market failure is very much a disqualification.
Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 02:31 PM Pacific Standard Time To: Hallam-Baker, Phillip Cc: Brian E Carpenter; John Leslie; [email protected] Subject: Re: "Discuss" criteria -------- Original Message -------- >> From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > >>> 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 mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
