From: Brad Templeton (brad@templetons.com)
Date: Mon Jul 02 2001 - 18:24:07 CDT
> >> I vote that we decide this is out of scope and will just needlessly
> >> complicate our standard, given that we don't anticipate widespread use
> >> of message/partial on Usenet anyway, and at most note this problem in a
> >> NOTE. Those who care can take up the matter with ietf-822 and hammer
I think we do anticipate widespread use of message/partial unless we make
a push for simply using large articles below some size (like 5MB).
Multi-message uuencode is quite common today, and message/partial would
be of course quite a bit superior to that.
I've been pushing this debate so we can lay out the groundwork for the
expected and desired switch to message/partial (which parallels the shift
from uuencode to MIME base64 encodings.)
I think the write answer is to deprecate the use of either multi-message
format on articles that are smaller than some fairly decent size, and
encourage the use of large articles unless a specific group has policy
otherwise.
For most users (ie. the considerable majority now using Netscape and MSIE)
the large MIME articles will simply work in their newsreader. The
multipart uuencodes and I think message/partials _don't_ work for these
users.
Message/partial can still exist for very-large articles (primarily large
audio and video files today, possibly some software distributions) However,
done right, its use will be rare, and newsreaders don't need to support it
directly -- saving the parts to a large file and having an independent
reassembly program makes sense.
What's wrong with what the spec says now? Not that much, it just needs a few
tweaks. I am mostly debating those who think we should leave things in
a state that causes lots of message/partials with small components and
makes newsreader authors think they have to do something about it.