[Top] [All Lists]

Re: large messages

1991-08-17 15:11:51
One more observation on this "large message" problem, for the people 
whose solution is to say "your problem" or "their problem".

Let's look at who really has a problem here.

There are three separate issues, I think:

(1) The IETF mailing list is trying to send a moderately large message
to a user on CompuServe.  CompuServe will not accept that message, 
rejecting it at 50Kb.  With a threshold at 50Kb, rather than 64Kb, they 
are out of compliance with HR.  Too bad; that isn't the only reason they 
are out of compliance with HR.  They handle the error situation in a 
reasonable way.  Who has a problem?

  -- well, the user may have a problem, if he or she is concerned about 
getting the monthly report.  Maybe he or she isn't.  If the report is 
critical, then, as has been pointed out, CompuServe may not be the right 
service.  Their policy is pretty clear.  Unless the erosion of users 
becomes serious, this is not a CompuServe problem--they chose a policy 
and just need to live with it.  And it is certainly not an internet 

  -- The IETF mailing list may have a problem, in that it has to send 
the 51st kilobyte in order to determine that CompuServe isn't going to 
accept > 50Kb messages.  If that is a problem, then SMTP is broken, or 
at least inappropriate for transmission of large messages.

(2) CompuServe said "why don't you break this into pieces"?  Reasonable 
request, can't hurt to ask.  But it is not, in and of itself, a problem. 
the IETF list can either agree or not agree.
  I suggest, Sam, that you don't, in fact, want to ask for that until 
and unless you manage to do some overhauling of your per-user-mailbox 
error handling.  Otherwise, these biggies, arriving in fragments, are 
going to cause a lot of "no more space" messages, and we know those are 
not handled very well.  So, if this suggestion were accepted, CompuServe 
would have a problem.  If it were not accepted, they may not be able to 
offer a slightly marginal service to their users.  As problems go, 
probably not a big deal.
   If it were partitioned, the monthly report arrives for all the rest 
of us in fragments and possibly not in order.  That is, at best, a 
nusiance and, at worst a problem.  
   Now, one could, of course, maintain two ietf mailing lists: the "big 
mail" list, and the "small mail" list, with the latter getting little 
chunks.  I suggest that option is a problem, if for no other reason than 
a perception that Jon and Ann have a large collection of other things to 
do with their time.

Stef says...
A basic premise of communications theory is that if you want to
communicate something to someone, you should make it possible for the
target recipient to receive and understand what you are trying to
   Yes, but maybe "we" don't care.  Maybe it is the responsibility of 
anyone who needs this information to receive it in a way in which it can 
be received.  Maybe they should look for someone (or some automated 
agent) on the Internet who receives these things and can break them up
into pieces before forwarding, possibly for a fee.

If you do not wish to communicate with the target recipient, then it is
easiest to just not bother to send anything.  It is pretty silly to send
stuff that will not be received.  
  But, as often happens with Stef and me, I had exactly this thought and 
concluded not "make into two messages" but "maybe mailing this sort of 
thing is the wrong model".  His argument about relative efforts clearly 
applies to either approach.

So, in my view, the burden of breaking the messages up into smaller
sized bundles is properly laid upon whoever wants the information to be
  Seems to me that is CompuServe's customer, who, if this information is 
wanted, should be looking into appropriate arrangements, whatever they 
might be.
  Things would be different if Jon had come on the list and said "hey, 
it went over 50Kb and a major chunk of the on-internet sites started to 
reject".  Then we would have discovered that the 64Kb limit in HR does 
not reflect current implementation reality (or, as asserted, the "de 
facto mimimum"), and, probably, that things should be repackaged until
there was a much higher level of conformance. As Bob Braden put it,
  But as long as it is a few users, on the far side of gateways, then 
the answer ought to be "their problem" (and I think I mean the user's, 
not CompuServe's, unless the latter makes a policy change) rather than 
motivation for inconveniencing the Internet users.

I'm also feeling the desire to pick a nit here.  Let's assume that we 
have an enforcement model, and we can, e.g., paint anyone green who does 
not conform to a MUST in HR.  Does CompuServe get painted green for 
imposing a 50Kb limit, rather than 64Kb?  I suggest that they do not!
  Now, if I impose a 50Kb limit, you get to paint *me* green, but how 
about CompuServe?  In the mail area, HR, like 821 and 822 before it, 
carefully avoided specifying the behavior of other systems and networks 
that sit on the far side of gateways off the Internet.  CompuServe isn't 
an "internet host" or collection thereof by any reasonable definition.
  So, suppose we send them a 65Kb message, and they "accept" every
single byte of it, and send back a 250 (?) code after they get the
CRLF.CRLF.   The "internet side" of the gateway is now conforming, they 
have "received" a 65Kb message.  Now they mail the thing back to you in 
a message that says, very politely, "the CompuServe network side of this 
gateway refuses to process messages over 50Kb".  We can't impose a 
requirement on their message sizes or formats, as long as they behave 
properly wrt anything they put onto, or get from, the Internet.  I 
suggest that this is proper behavior, if not wonderful, and we can keep
the green paint. 
  And, as Stef says, "it is pretty silly to send stuff that will not be 

<Prev in Thread] Current Thread [Next in Thread>