ietf-nntp Size Extension to NNTP?
William H. Magill
magill at isc.upenn.edu
Mon Aug 26 08:07:03 PDT 1996
> >> NNTP does not rely/use/need/refer-to MIME.
> The RFC would have referred to MIME, had MIME existed at the time we
> wrote the RFC.
> MIME-formatted message ARE in use on Usenet.
> On the other hand, the NNTP RFC defers nearly all specification of
> the format of messages to other documents (RFC1036 et al), and any
> reference to MIME would, as Stan suggests, more properly be in those.
One interesting question / side effect of the use of MIME on/for NNTP.
Granted the issue may be somewhat moot if one accepts that MIME
encoded messages may exist only in "alt.binaries..."
I serve both as postmaster and newmaster for upenn.edu, a fairly large
domain. Over the past month I have seen a HUGE increase in the number
of bouncing MIME encoded mail attachments in the multi-megabyte range -
Historically, I used to see a random, large message bouncing around the
place. Lately I've been seeing at least one a day - I'm REGULARLY getting
5-25 megabytes worth of bounce messages, which usually represents only 5-10
actual messages, but where 1 or 2 messages are huge.
These messages are students shipping drafts of papers to each other;
faculty members exchanging papers with colleagues and idiots shipping
source code for entire subsystems (like cu-cme) as mail messages.
They are all MIME-encoded attachments.
But with POP mailers, like Eudora, shipping anything as attachments is
trivial! (And as desktops get more powerful, it takes less and less time
to encode these suckers...)
These messages bounce because most systems on campus only give individual
users 3-4 meg of disk space (including incoming mail), and because many
systems (personal workstations, typically) don't even have that much disk
space in /usr/spool in the first place.
The point is - the sender is not doing anything either stupid (in 99% of
the cases) or undesirable (ie, we do not discourage the use of MIME and
attachments on campus). The sender is shipping a document which they
believe to be "trivial" via the mails. And they believe it to be trivial
because it is so easy to do, and there is no mechanical thing either
stopping them or warning them that what they are doing is evil.
(Let alone breaking things up in to rational-sized chunks "automagically"
News has traditionally had a 50K message size, threshold of pain.
Will there be any sort of "differentiation" between messages acceptable
to backbone T3 connected servers and those still connected via traditional
(hopefully) 14.4 uucp connections?
So I guess the RFC needs a "size extension" concept?
The concept of "class of service" comes to mind -
High Speed services - able to accept huge messages in a single gulp
[Where "gulp" means very few seconds per message.]
moderate speed service - able to accept huge messages after chewing
on them for extended periods of time at the
sacrifice of lots of little messages.
[Where "extended periods" means minutes per message.]
low speed service - barfs on huge messages - always accepts messages
queued (ala the old BITNET, RSCS queueing) smallest
first without regard to time in the queue.
[And/or messages <50K by time >50K strictly by size,
if nothing <50K exists]
These classes of service could be applied equally to both server and
reading clients. Today's news readers, that I am aware of, don't give you
an option to "NOT-download" a humunguous message. Most, like the latest
version of Netscape, simply ask you "how many messages" not "how many bytes
worth of messages".
I can envision a news reader which would ask me (ala GNUS "How many messages
to read" and FETCH time estimates) ... This message is "bytes long" and
will take "time" to download using your current average download speed of
William H. Magill Senior Systems Administrator
Information Services and Computing (ISC) University of Pennsylvania
Internet: magill at isc.upenn.edu magill at acm.org
magill at upenn.edu http://pobox.upenn.edu/~magill/
More information about the ietf-nntp