Perry: I may have missed something, but I don't see where synchronization is a concern. The whole of idea of Kermit is to provide a "binary" path between two computers. It is Kermit's responsibility to ensure the data is received in the same order as sent (sychronization is part of the Kermit protocol, no?). If we have a data stream coming from a keyboard or whatever, which we run through an invertable encryption algorithm, and then pipe it into Kermit which makes sure it gets to the other side, Kermit need not know where the data is coming from. The other side of course has to know the protocol and the key... I believe that Kermit allows variable sized packets per file transferred, but does it allow the packet size to vary during the transfer? I'd have to go find my Kermit protocol reference on that one. You would want this, as well as a relaxed timing on the protocol, if its to come from the keyboard, as a user does not (and/or cannot) normally type as a consistant rate... --- Nick MacDonald | NMD on IRC i6t4@jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger On Mon, 12 Apr 1993, Perry E. Metzger wrote:
A good idea, but getting the protocol right is hard -- you don't want to put any real overhead on the line, but you also want to do error detection and resychronization so that your cypher will run properly. Discussing a proposal for a line protocol that has these features would, of course, be germane to the list.