--On 10. september 2001 16:53 +0100 Lloyd Wood <l(_dot_)wood(_at_)eim(_dot_)surrey(_dot_)ac(_dot_)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