[list.ietf-nntp] IMAGE {opsys}?

lear@turbo.bio.net (Eliot) (06/24/91)

Should we just instead have a BINARY command which transmits random
data in network byte order?

sob@tmc.edu (Stan Barber) (06/24/91)

Given the experience with FTP, I am not sure that BINARY is a good long
term solution. All the world is not stream oriented.

On other topics:
        I think OPTION is a good idea. If we need shortcuts, we should use
        something like "OPTION LOCAL something" that would set up a bunch of
        options in one transaction.

        
        I am more and more convinced that NNRP needs to happen. I have been
        considering the idea of NNTP slave servers and I am convinced that
        NNRP slave servers make more sense.


        I am going to have more to say about the draft before July 4th.


-- 
Stan           internet: sob@bcm.tmc.edu         Director, Networking 
Olan           uucp: rutgers!bcm!sob             and Systems Support
Barber         Opinions expressed are only mine. Baylor College of Medicine

brian@UCSD.EDU (Brian Kantor) (06/24/91)

The idea was to provide a non-machine-independent way to shove a file
from one end to the other.  If you ALSO want a BINARY, fine, but that's
not at all the same thing.
	- Brian

lear@turbo.bio.net (Eliot) (06/24/91)

Brian is, of course, correct.  IMAGE and BINARY are two distinct things.
 I was asked by someone else exactly how the two differ.

IMAGE allows for optimizations to occur.  For example, the elimination
of CR/LF conversion.  BINARY is essentially a raw byte copy.  In some
instances the two will have the same results.  However, if a machine
that uses CR/LF as the end of line transmits BINARY to a machine that
uses LF as EOL, the message would not appear as the same information at
the other end.

Another example (only slightly far fetched) would be two systems that
store information in a compressed form.  An appropriate IMAGE mode would
allow them to communicate the compressed information directly without
first converting back.
Eliot Lear
[lear@turbo.bio.net]