From: Brad Templeton (brad@templetons.com)
Date: Tue May 07 2002 - 19:44:51 CDT
On Tue, May 07, 2002 at 05:14:41PM -0700, Russ Allbery wrote:
> Andrew Gierth <andrew@erlenstar.demon.co.uk> writes:
>
> > there are probably more, but I have some real work to do at this point.
>
> MIME-style parameters are introduced wholesale in existing headers rather
> than just in newly added headers, and there is, so far as I know, no
> operational experience with this.
All that's required here is a statement that implementations ignore
everything after the first unquoted semicolon. This is done only for
headers that didn't allow or never used a semicolon, so where's the harm?
The benefit is down the road it makes them extensible, which is about
the greatest benefit a spec can add to a feature.
>
> In general, I'll make the comment that if someone has a really great idea
> about how to improve Usenet and it doesn't get implemented by any major
> server, it's quite possible and possibly likely that either the idea isn't
> actually a good idea or it is a sound idea that doesn't actually improve
> things sufficiently to be worth implementing. If no one bothered to write
> and deploy the code, it's rather questionable whether it should be in a
> standards-track document.
And the reason I say the above is that USENET is hard to experiment with.
It's hard for developers to add new globally useful functions. You can
add new headers (and many have done so) but if their goal is to change
behaviour netwide it's almost impossible.
Thus if I could have the standard do one thing and one thing alone it would
be to help extensibility. Thus, for example, the approach of accepting
MIME parameters. And the new Distribution semantics.
In most other media, you have the ability to easily do small scale
innovations that grow. Web sites can try a new feature, and even see
which browser is coming in to serve up things differently. E-mail tools
are one-to-one, so they can know if the other user supports a new feature
and use it in mail to her. On USENET you have to assume the target of
a message doesn't support the new feature.
Perhaps the thing that cursed USENET the most took place when people flamed
multipart/alternative postings and scared people from using it on the net.
In part, this was Netscape's mistake, as they used it when it wasn't needed.
And it's also the problem that multipart/alternative is deliberately
inefficient, which is OK for mail but less appealing in news.
What USENET needs more than anything is solutions that make it easier to try
new things. Then we could indeed have lots of nice existing practice to
put into the standard.
Some factors which would help are:
a) As noted, embracing multipart/alternative
b) Make everything extensible that can be
c) Provide a distribution mechanism so that articles with new features
can reliably move only in distributions where they will be properly
handled. Consider even the ability to post two forms of an article
with two different and complimentary distributions (eg. "newnet" and
"!newnet") and have it work.
But otherwise, you're right. There's not a lot of deployed code. In fact,
a typical USENET message today looks almost identical to one from 15 years
ago. Almost nothing else in the computer industry looks the same as 15
years ago. I don't take this as a sign that it was perfect and innovations
are undesired or uninvented.