From: Brad Templeton (brad@main.templetons.com)
Date: Wed Nov 03 1999 - 15:07:53 CST
On Wed, Nov 03, 1999 at 02:40:22PM -0600, G. James Berigan wrote:
> Brad Templeton <brad@main.templetons.com> wrote:
>
> > Should not mvgroup, like all new features, be extensible in the
> > standard way? There is no excuse for designing new features that are
> > not extensible, not in the 90s.
>
> What would need to be done to it? I've been gone for too long I guess.
> How are we making things extensible?
The whole point of making things extensible is you don't know at the time
what would need to be done to it! A good fraction of all the upgrading
and interoperability problems in the world come because people didn't
think enough about extensibility when they designed formats and protocols.
It is my position that you need a tremendously good reason to design a
new format or protocol without making it easily extensible. I hope most
agree with that.
I've gone further than some in a few ways. I think we should define all
our headers that we can as extensible, in that all new software should
parse and discard any extensions, so that eventually all headers are
extensible in the same fashion. However, I haven't sold that.
I also happen to think that a good extensible system provides some means
to make extending easier, including:
a) Classes of extensions, as in:
1) If you don't understand this, just ignore it
2) If you don't understand this, give a warning
3) If you don't understand this, abort
b) Macro facilities that allow you to say:
"If you don't understand this, treat it like X"
Now not all these can go into USENET headers, but they are all good things.
At a minimum, I had hoped there is support for the idea that all new
elements -- new headers, new control messages -- be defined as extensible
in MIME format. No exceptions.