Re: Last Call: Using SOAP in BEEP to Proposed Standard

[Harald Tveit Alvestrand <harald at alvestrand.no>]

--On 10. september 2001 16:53 +0100 Lloyd Wood <l.wood at eim.surrey.ac.uk> 
wrote:

> That's very W3C fast-track approach. It strikes me it's not the IETF
> standard cycle, which has been known to take... well, rather longer.
>
> I can't see feature negotiation working well in implementations; it's
> nice in theory, but often problematic in practice. The feature
> negotiation described in your draft seems clean and simple, but see
> further comments on this at end. I'm not convinced it's needed.

just about every single protocol I've watched has gone through a some 
standard stages:

1 - "The problem space is simple. We will define everything we need."
2 - "We can handle the needed new features by reissuing the protocol."
3 - "As long as we provide a registry for new features, we will be OK."
4 - "As long as we do vendor spaces for new features, we will be OK."
5 - "As long as we have mandatory/optional extension flags, we're OK."
6 - "How did we end up with such a complex protocol? Let's kill it!"

Feature negotiation is required at all stages beyond number 2, and 
sometimes even at stage 2; it depends on the new features.
Numbers 4 and 5 sometimes trade places, and number 6 can occur at any time.

That's life.

(Real, named examples: HTTP, Receipt notifications, X.400, X.500, PGP/MIME, 
LDAP, BGP, DHCP, SRVLOC, URLs.....counterexamples would be harder to 
find....)

                 Harald