From: Russ Allbery (rra@stanford.edu)
Date: Tue Jul 03 2001 - 13:51:09 CDT
Brad Templeton <brad@templetons.com> writes:
> Um, this is going in circles. I'm proposing that the standard require
> that the software _technically_ handle articles of a least "X" (where X
> to my mind would be in the 5MB range though some like 1MB) so as such,
> the main reason a site would put on such a limit would be for policy
> reasons, namely to conserve resources.
That's pretty much a no-op requirement; I don't know of any news server
software that can't already handle 5MB files, or for that matter files up
to at least the size of physical memory (which is where INN runs out of
steam, since it wants the whole file in memory before doing further
processing of it).
The other issues that people have talked about with slow feed propagation,
restarting of downloads, and so forth aren't a case of bugs in software,
just a case of missing features that would be nice to have to handle large
files efficiently (something that Usenet software by and large is *not*
designed to do since large files were always the unusual case; I don't
know of a news server designed specifically for binaries that's widely
available).
> These sites would not say "we want the megabyte articles if they are
> annoyingly split up into 20 parts" It doesn't want them at all.
You do realize that this isn't the issue that I, at least, am arguing at
all, right? You keep repeating this like it's a rebuttal to someone's
argument, and I'm not aware of anyone who's arguing this point with you.
> No, I haven't avoided it. You know how these threads get. Nobody knows
> what "smaller than they must is" because the standard provides no
> guidance.
1MB and 10MB are the most widespread existing practice; if we need a limit
written into the standard, one of those is probably the right one to
choose.
After thinking about it for a bit, I see your point and reasoning behind
saying something about this. The best wording and place in which to say
something here isn't immediately obvious to me, but I can see situations
where having that written down somewhere would be reasonably useful.
The difference between news and mail in this regard (and for *any* place
where we say anything at all about something defined in mail, I want to
see a very clearly defined reason why news *has* to be different than
mail) is that there's reasonably widespread agreement between servers on
maximum article size, clustered around 1MB and then around 10MB, whereas
mail servers are all over the map. I'm not sure if that's a sufficient
difference to warrant adding any text over the existing MIME description,
but it's at least arguable.
> Anyway, it probably is time to end this. I mainly wanted to defend the
> philosophy (while we still have the chance and the switch to
> message/partial from multi-article uuencodde has not yet begun) that
> article disassembly and reassembly belongs in the transport tools, not
> the article format.
The problem with your defense is that it's a pointless exercise in
abstract philosophy unless you or someone else intends to write the
transport tools to do that, and discussion of *that* is completely
off-topic in this working group. (And it isn't going to get done in the
one year to two year timeframe.) So that sort of philosophical argument
really has no bearing on the construction of a standards document *now*.
It would have bearing if you had an implemented proposal for how to do the
disassembly and reassembly at a different layer, but so far as I
understand it, you don't.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>