--On 10. september 2001 16:53 +0100 Lloyd Wood <[EMAIL PROTECTED]>
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
