Re: Correcting Corrections Re: EDI over http

[clueder@xxxxxxxxxxxxxxxx (Christopher J. Kit Lueder)]

That is why MIME uses BASE64 encoding or SMTP users invoke UUENCODE, to
provide transparency of contents and to force line wrapping. Not a problem
unless you disable the BASE64 encoding.

    _/    _/             Kit C. J. Lueder       
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Page: 800-541-1485
 _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
_/    _/  _/    _/   McLean, VA 22102        Mail: kit@xxxxxxxxx
"I don't want to achieve immortality through my work ... I want to 
achieve it through not dying." -- Woody Allen  

>>Note a few corrections to info in prior messages:
>>1. SMTP does not have a limit of 1000 bytes. TCP/IP breaks a stream
>>into packets (same for HTTP/SMTP/SSL) but glues them back together,
>>recovers missing packets, etc. before the application reads data.
>>Some non-SMTP gateways have a limit, and some sites limit the size,
>>but there is no limit to SMTP messages other than disk space.
>RFC 821 Section 4.5.3
>
>The maximum total length of a text line including the <CRLF> is 1000
>characters (but not counting the
>leading dot duplicated for transparency).
>
>There is a limit on how long you go without a CRLF in the original RFC.
>That is what I referred to.
>It could be that at the TCP packaging layer a given system would packetize
>on a boundary of its choice.
>But often newlines mark boundaries that will be unbuffered and sent out.
>So on the wire the packets tend to come when the writes come and the
system
>does not buffer indefinitely.
>So all of what you say really abstracts away from the varied details of
>buffering by the OS implementation of
>sockets. The same holds when you simply say that end to end they are both
>TCP and so are identical. There
>is a level of detail that this ignores. But I do not wish to continue this
>thread in a IETF WG list because these
>are not standards issues. (And yes following the statement about limits,
it
>does say that implementations should
>try to impose no limits...)