Path: utzoo!telecom-request Date: Mon, 20 May 1991 16:04:58 GMT From: "Marc T. Kaufman" Newsgroups: comp.dcom.telecom Subject: Re: Hayes Wins Damages on its Command Set Patent Message-ID: Organization: Computer Science Department, Stanford University, Ca , USA Sender: Telecom@eecs.nwu.edu Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 381, Message 3 of 10 Lines: 36 In article johnl@iecc.cambridge.ma.us (John R. Levine) writes: > In article is written: >> The ability to do that in a way that guarantees that escape to >> command mode won't accidentally be invoked by the data stream >> would be difficult (I can't think of a way) without timing and >> a unique string being an essential feature of the escape from data >> mode. > The other approach is to reserve some character sequence to mean > switch to command state, and to have some way of protecting that > sequence if it appears in data, most typically by doubling the first > character of the sequence. This works perfectly well, and is what one > does with synchronous modems, but means that the communications > software on each end has to do some of the filtering, while the timed > technique has the advantage of the escape sequence being so unlikely > in the normal data stream that no protection is necessary. Funny you should say that. In fact, the usefulness of "+++" is fast coming to a close, because many modems are at the far end of a network with buffering, and there is no good way to insert "time" into a buffer. My understanding is that the next generation of modems will use the old BiSync technique of DLE (Data Link Escape) + character to send commands to the modem. DLE + DLE will be sent as a single DLE to the other end. There is no more problem with this (from the point of view of computers) than there is with XON/XOFF. (Yes, I know that BiSync used DLE as a framing escape rather than a modem escape, but the principle is the same) Marc Kaufman (kaufman@Neon.stanford.edu)