>The returned data might look like:
>
> 0200 document follows
> Content-Type: application/octet-stream
> Content-Transfer-Encoding: packet
>
> 4000
> ...4000 bytes of stuff...
> 1745
> ...1745 bytes of styff...
> 0
>
>Then the connection would be available for another transaction.
I like this. I'm not entirely happy with aggregate's use of a
"dot on a line by itself", but there is certainly precedent for that.
But CTE packet could work.
I attacked the very same problem with the SIFT/UFT protocol.
This is a protocol for sending files, kind-of a combination of LPR/LPD,
SMTP, and FTP. (there are reasons why I wanted to invent another wheel)
I don't remember if RFC 1440 was up to this level or not. SIFT has
changed for the better since they put out 1440. It goes something like
.... other session verbs/commands, like "NAME", "USER", "TYPE" ...
DATA 4000
....4000 bytes of stuff...
DATA 1745
....1745 bytes of stuff...
EOF
.... other verbs/commands, ending with "QUIT" ...
.... (you could have an "ABORT" if there's trouble) ...
The problem is that you have to "switch modes" from CR/LF lines
to byte counting. This is quite significant if your O/S isn't byte
oriented. I did the original work on VM (CMS) which is heavily record
oriented. All that mode switching is why you've heard me whining about
Content-Length -vs- something like a line count, though I don't really
see any other way to do it over TCP unless you want the overhead and risk
of "boundary" pattern matching.
So ... you get my vote, Dan.
>Dan
-- Rick Troth, <rmtroth@aol.com>, <troth@ua1vm.ua.edu>, Houston, Texas, USA