Date: 7 June 1983 04:10 EDT From: Robert Elton Maas Subject: Proposed changes in Simple mode To: PCNET-PROTOCOL @ MIT-MC In the event a general PCNET policy decision is made that the current Simple-mode protocol isn't suitable because it uses atsign which isn't passed to user programs on Honeywell and Interdata systems, we must decide exactly what change to make in the protocol to solve this problem. It's also possible no policy decision can be made at all and we must change the protocol (or not) on our own initiative. Tonight I've indexed the current debate on how these changes might be made. If you want to help make this decision, ask me for the nodes of interest listed below (persons on MIT-MC may use the INFO program directly of course, at greater efficiency). File: DEBATE, Node: new simple details, Up: Computers that can't handle ASCII Assuming we make a protocol change of some kind to adapt to Honeywell and Interdata computers, exactly what kind of change? * Menu: Possible workable ideas... * Hello negotiation starting from hexadecimal:hex hello * Fourth PCNET mode, simple-but-no-atsign:fourth mode Neither of the above requires any change in normal Simple nodes * Extra characters ignored by current software:hack framing The above requires change only in transmit string in normal nodes * Change Radix-41 mapping, HDX turnaround, and packet framing:change simple The above proposes an incompatible change in Simple mode, and goes far beyond the original problem of atsign * Packet framing change:pak fra This suggestion could be used in a fourth mode or as the standard. Unfortunately the suggestion as made doesn't reframe the UART. * New experiments in reframing UART:UART exp Atsign is the only reasonable character which by-itself can reframe a UART, unfortunately it's not a FORTRAN character Unworkable ideas, can't be done on many systems... * Realtime pauses:: * Doing a RESET of the UART device:reset UART  Date: 20 May 1983 19:39 EDT From: Robert Elton Maas Subject: characterset for Simple mode To: fylstra.tsca @ SRI-UNIX cc: PCNET-PROTOCOL @ MIT-MC It occurs to me that the amount of code to perform a two-way split of direct offset (if Radix-41 is in two congiguous segments) is about the same as the amount of code to intialize a direct-lookup table by inverting another table. Furthermore, inversion is much more robust than the offset method. (Often you have < when you should have <=, or vice versa, causing obscure bugs in the offset method that aren't detected until you receive a packet that happens to have the legal character that you are accidently rejecting or some illegal character that your code is accepting, the latter kind of bug is very hard to locate!) If the random-ordered characterset is at least reasonably compact (not many unused characters between the two extremes), then the amount of table space for the inverted table is reasonably small. I think modifying the protocol to make this piece of code doable in the bug-prone direct offset method is at best a waste of our time an at worst a bad idea. Other matters, like the PREAD/PWRITE interface that Gilmore and I developed before the workshop, that allow applications to call PCNET I/O as subroutines, instead of vice versa, our geographical&telephonenumber addressing system, that allows punting to direct dial or to forwarding thru a gateway in the destination's vicinity, are much larger savings of programmer effort, and large matters like these ought to occupy most of our time instead of changing the low-level characterset again and again to satisfy petty complaints. Perhaps making it run on Honeywell is important; that's a political decision. But making the characterset contiguous is a red herring in my opinion. Making the representation a superset of IBM hexadecimal, and hence a superset of ordinary numerical representation, so that documentation and debugging will be unconfusing, is a subtle point I don't feel strongly about (after all I was willing to put up with the original character set where "(" had the value zero, "0" had the value one, "1" had the value two, etc.). Perhaps others will have a strong opinion whether making "0" have the value zero and "1" have the value one etc. is worthwhile for avoiding confusion or just another unimportant desiderata to ignore.  Date: 20 May 1983 19:19 EDT From: Robert Elton Maas Subject: Radix-41 charset, packet framing, etc. To: fylstra.tsca @ SRI-UNIX cc: PCNET-PROTOCOL @ MIT-MC Realtime delays in output behaviour are *impossible* on many computers where I/O goes through an operating system (Tops-10, BIOS, et al; I'm not saying these particular systems don't implement real-time delays synchronized with output buffering, just examples of operating system I/O). One major problem with buffered I/O is that calls to output data are asynchronous with actual UART output, thus even if real time delays are available, they are useless to cause pauses in UART output. Radix-41 is supposed to be the common denominator among such operating systems that don't provide direct 8-bit memory-bus access to I/O devices from user-mode programs. If we're going to kiss Honeywell's use of ATSIGN as a control character, we ought to be aware of many many systems that can't synchronize realtime delays with system-buffered I/O. Also it's virtually universal that whenever we piggyback on another network, such as Arpanet for testing/debugging and some commercial network for avoiding direct voice-grade long-distance charges when sending long messages, the facility for synchronizing end-to-end I/O with realtime is totally absent. Thus I'd prefer multi-character non-pause packet framing (such as space ), which should work on any system, rather than any realtime pauses, which work almost only on dedicated micros with direct program access to I/O device-registers.  Date: 19 May 1983 at 1811-PDT To: Robert Elton Maas , pcnet-protocol @ Mit-Mc cc: Sigurd.UDel-CC-Relay @ Udel-Relay, G.Harris @ Su-Score, fylstra.tsca @ Sri-Unix Subject: Re: Radix-41 charset In-reply-to: Your message of 9 May 1983 09:54 EDT. From: fylstra.tsca @ Sri-Unix Received: from SRI-Tsca.micom by SRI-TSC.micom with rs232; 19 May 83 18:22-PDT I just returned from a vacation ... hence the delay in replying. I nominated the ordered set of characters +,-./0123456789A .. Z because this represents two contiguous subsets of ASCII; your suggestion involves three subsets. I was trying to appease those who had argued for a change sometime ago that would draw the R41 set from a minimum number of contiguous subsets of ASCII. It really doesn't matter to me; the C version uses table lookup for both directions and uses one string to create both encoding and decoding tables, so it is an extremely trivial change. The 0..9A..Z+,-./ ordering is fine with me. As for line turnaround characters, your reading of my spec was the right one, i.e. [ becomes (, ] becomes ). As for at-sign, my preference is to remain within the 1966 ANSI FORTRAN subset of ASCII, thus excluding at-sign as a permissible character. I'm still not convinced that UART reframing is such a terrible problem, but I admit to not having studied the behavior of various ASCII characters experimentally. It would be nice if someone could perform a few experiments to validate REM's result using different equipment. The best way to guarantee reframing before each packet is simply to PAUSE for one full character time (i.e. hold the line marking and do not transmit anything, not even FF hex or DEL). I suspect that one reason MODEM2 works so well is that there are pauses of reasonable duration after each packet transmission. In fact, MODEM2 involves at least one full character time of line mark after each transmission, during which the recipient replies with one ACK or NAK; this duration is even longer when the recipient pauses to write to disk. This works because MODEM2 is a half-duplex protocol. Dave Fylstra  Date: 6 May 1983 04:00 EDT From: Robert Elton Maas Subject: Atsign vs. spaces for UART framing, new idea / debate To: FJW @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC I don't like the idea you suggest. Each time the UART is reset, it makes matters worse not better. Each time it's reset, it picks up bits in a random place in the incoming stream, with 90% chance of being wrong and 10% chance of being right. It then waits until it sees a 1-->0 transition, which could be in the middle of a character if there is a 1-->0 transition after the place you reset it before the next actual character. With data coming in continuously in full duplex mode, a very large number of packets may be lost before it randomly locks into correct frame. In half-duplex mode, it will always get an error during the lead-in, and always reset by your method, and thus have a very high induced error rate even on crystal clear phone lines. Furthermore it will often be out of correct frame when it hits turnaround, thus often miss turnaround totally and need a timeout, thus totally defeating our majority-logic method for making timeouts extremely rare. -- Let's stick with self-reframing data at the two lowest layers (half-duplex and packet framing) when using serial asynchronous (UART/ACIA) data methods. (They are device-dependent anyway, on X.25 synchronous devices turnaround and packet framing is done by the hardware using a completely different method).  Date: 5 May 1983 23:25 EDT From: Frank J. Wancho Subject: Atsign vs. spaces for UART framing, new idea To: REM @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC In-reply-to: Msg of 5 May 1983 19:05 EDT from Robert Elton Maas It's not all that clear to me that you really want to have the stream attempt to self-sync anyway. In the various implementations of MODEM2, etal., it's the receiving end that is supposed to detect a misframed character, force-reset the U(S)ART, report the error up a level (maybe), and press on. Thus, the same sort of low-level hackery should be done for the PCNet protocol as well - i.e., in the device handler, and the protocol should not be bothered with such device dependencies. --Frank  Date: 5 May 1983 19:05 EDT From: Robert Elton Maas Subject: Atsign vs. spaces for UART framing, new idea To: PCNET-PROTOCOL @ MIT-MC A couple days ago I did another round of experiments, this time with my borrowed Datamedia 2500 instead of my Beehive that I did the 1977 experiments on. Data was generated by my 6502 computer as before. I interrupted the data stream by momentarily loosening the EIA 25-pin connector on the RS-232 port connecting the 6502 and Datamedia. The Datamedia has something called "tape mode" whereby all characters are treated as printing. It shows only 7 bits (the parity bit is ignored), and NUL shows exactly the same as SPACE on this IMSSS ROM (the standard Datamedia ROM has them different), but for the most part it allows one to determine whether the UART is in correct frame (correct data showing on screen) or incorrect frame (some other character, a rotation of bits in the start+7+parity+stop cycle). Atsign with mark parity again is totally resistant to UART mis-frame, as are the other characters with only a single transition in each direction (NUL with either parity, mark-back-apostrophe, mark-lowercase-p, mark-lowercase-x, mark-vertical-bar, mark-close-brace, and mark-rubout). Other characters, such as the proposed SPACE, suffered UART misframe. Once UART misframe happened, it persisted forever (many minutes) unless the RS-232 stream was interrupted again (in which case it'd fall back into a random state, sometimes the correct one, sometimes another) or I switched the 6502 to transmitting a different character that didn't have a mark-to-space transition at the spot that had been locked onto. I conclude that SPACE isn't a good lead-in character, since a significant percentage of the time the wrong UART phase will be caught when the node that just finished transmitting now starts listening (if it resets the UART, it'll pick up at a random point in bit stream, while if it doesn't reset the UART it'll get data overrun errors and who knows what else, possibly be out of frame anyway). There is one alternative to atsign and the other good re-frame characters (non-FORTRAN) and space (fail to frame UART). We could use a particular sequence of different characters, all FORTRAN, which force-rotate the UART frame bit by bit until it's correct. I'll have to look at possible sequences and see if I can find a good one. We could send SPACE to rotate the frame to within two bits of the correct position, then one or two other characters to finish the task. What do you think of that for Simple mode? (For advanced mode, we can use mark-atsign or even mark-NUL if we want, since we aren't constrained by the FORTRAN characterset.)  Date: 1 April 1983 05:08 EST From: Robert Elton Maas Subject: Mapping multi-window+edit user interface across a net To: PCNET-PROTOCOL @ MIT-MC, WORKSTATIONS @ MIT-MC cc: PETTIT @ PARC-MAXC, DDEUTSCH @ BBNA (This is just a summary of how this proposed protocol might work and what it'd be used for, not proposed formal specs which come much later.) File: PROTO, Node: EWIND, Up: Application programs Please read and understand the TELNET protocol before attempting to read this. Also to appreciate this service one should be familar with multi-window editors such as EMACS and/or with multi-window shells (execs) such as various Xerox systems, Swinehart's ETV-based proposal, the ETV-based interface to MacLISP "EMACLS" at SU-AI, the similar EMACS-based interface to MacLISP at MIT, Apple's LISA, or the Buroviseur proposed by the KAYAK project at INRIA. This is a generalization of the TELNET and the NVT (Network Virtual Terminal) protocols. It is designed to make full use of CRTs and other display terminals with random-access screen update. The basic concept is still that the user is typing on a keyboard and seeing results on a CRT. The difference is that the CRT screen is divided into windows, and each window corresponds to a different logical stream to the host. Furthermore, while some windows will be operated in standard teletype-emulator mode (keys pressed are sent immediately, and whatever comes back is display, typically end-to-end echo of what was typd plus anything output by the remote program), others may be operated in remote-display mode (keys pressed are still sent immediately, but the remote host has total control over what appears in the window), or in local edit mode (keys pressed cause the screen to change locally, nothing is sent to the host except when a special SEND-THIS command is typed or after the mode is changed back to one of the other modes). While text typed on the keyboard is normally sent to the job currently selected (the job corresponding to what window the cursor is currently in), text output from ANY of the jobs is immediately send from the host to the local system which upon arrival causes the appropriate window to be updated. Thus the user may be interacting with one program actively while watching several other jobs on the side. Text that appeared as program output in one window may later be edited locally and/or copied to some other window. Thus it's easy to prepare documentation containing edited transcripts of online sessions without disturbing the still-running program being documented. Text that was read in from a file in an edit window can be copied to another window so it can be fed as input to a remote program. Or for a simpler case, the user can be running some long program and editing an unrelated document on the same terminal at the same time, running the program in on window but editing in the other window most of the time, occasionally watching to see how the long program is coming along. It's even possible for single programs on suitable hosts to be connected to more than one PCNET EWIND stream, and thus be able to produce output of different types into two different windows. For example normal echo of typed input may appear in one window, normal program-to-operator output may occur in a second, error diagnostics may be emitted in a third (and the local system may be set to beep whenever anything is sent to this window), and finally two files of actual desired output may be written, one on the remote system and one into yet a fourth window on the local system. * TESTIMONIAL BY REM * I believe this kind of multiwindow interface, with many more specific features like splitting or appending two windows, making some windows invisible, keeping a window-status meta-window around, ... is the shell of the future, both for operating local multiprocessing systems and for operating remote systems via a network link from the local workstation/system.  Date: 1 April 1983 05:03 EST From: Robert Elton Maas Subject: Very preliminary sketch of PCNET TELNET protocol To: PCNET-PROTOCOL @ MIT-MC Not to distract you-all from your serious work on finishing the FTP1 protocol, but I randomly decided it's about time we formally specify or at least sketch out a TELNET protocol, so I did it tonite. (But see the next message after this for something even more wonderful!!) File: PROTO, Node: TELNET, Up: Application programs The purpose of the TELNET (also called virtual-login or virtual-terminal or remote-login) protocol is to allow somebody to connect across the net from his/her terminal to some host without being subject to errors caused by phone-line noise on the way. In the case of PCNET, it simply means an error-free link between the terminal and the CBBS or other host. The simplest implementation will have no method to abort data already in route. The abort facility is important on the Arpanet where perhaps a half minute of data may be en route and it's painful to have to sit and watch it stream out after a command to abort that and switch context has already been received at the host and acted on. But with direct single-link connections such as PCNET the abort facility is not essential. Nevertheless some commands may need to be sent along a different channel from the ordinary data. Thus TELNET will use two logical streams, one for ordinary data and another for end-to-end magic commands. (But at this time no actual end-to-end commands will be defined here.) SPECIFICATION: The application program is called TELNET. Ordinarily the originate node requests service which is granted by the answer node. Ordinarily the node requesting the service is the "master" or "user" while the othernode is the "slave" or "host". In the description below, "local" will mean "master" or "user" while "remote" means "slave" or "host". Two streams are allocated, #1 for TELNET-control messages and #2 for normal data. Any key pressed on the local keyboard is sent along stream #2 to the host where it is entered into the input buffer of a virtual terminal port assigned to the user. Ordinarily the user will first send a command to log in, then will send text (monitor/exec/shell) commands to various programs and data text to those programs. Finally the user will send a command to log out. All data output from the host thru that virtual-terminal port will be send back along stream #2 (remember all PCNET streams are bidirectional) where they will affect the CRT or teleprinter in some way. Ordinarily text characters will be written on the CRT or typed on the teleprinter while control characters will affect cursor or carriage movement. It is possible that certain keys on the user's keyboard will be defined by software in that local computer/PCNET system to affect the local computer/system instead of being immediately transmitted to the remote host. Some of these local effects may be to generate control messages along stream #1. Anything sent along stream #1 will be intercepted and acted upon by the remote TELNET program. Possible effects are to directly modify the environment of the user's job that is running on the remote system underneath the virtual terminal interface, or to indirectly affect that remote job by generating (at the host!) some text that is spliced into the stream of data coming into the host system from PCNET stream #1. It is also possible for the host system to send TELNET-control messages back to the local system along stream #1, either replies to TELNET-control messages sent earlier from the local system to the host system, or new messages totally initiated by the host PCNET system. For example, the host might send a message indicating the host system will be going down for maintenance in five minutes, and in response to this the local system might want to flash a warning countdown at the bottom of the screen or sound a beeper or even turn off the television set to avoid distraction during the critical last minutes. Note that unlike the Arpanet TELNET protocol which uses a single bidirectional stream, and thus needed to insert commands on the data stream by sending a code of hexadecimal FF preceding each command, and thus needed a way to quote FF if it ever appeared as normal data; PCNET uses two streams, so the one dedicated to data is totally transparent to 8-bit data and doesn't need any escape or quoting mechanism. Since the New-Telnet protocol on the Arpanet has withstood a lot of usage and experience, we might choose to simply use their protocol as is, with the only difference being the separation of control and data streams. Would anybody object to that? (I could FTP the relevant RFC and edit it to be correct for PCNET, and insert it here for reference.)  Date: 17 March 1983 03:30 EST From: Robert Elton Maas Subject: New explanation of our layers of protocol and corresponding software To: PCNET-PROTOCOL @ MIT-MC, PCNET-DESIGN @ MIT-MC, PCNET-WORKERS @ MIT-MC (Persons on more than one list, pardon the duplication.) Now that I've been reorganizing PCNET knowledge in a tree structure, I've decided to create an introduction to PCNET protocol in this form, keeping all the details and explanations in sub-frames in the tree, with only the introductory material and simple listing of reasons for each layer at the top level. Below is the top level of this new information frame. I'm sending it to all three working-group lists because all members on all three lists need to understand the layered PCNET protocol, and previous documents which were not tree-structured tended to be confusing so that many of you still don't understand what you're trying now to modify&augment (PCNET-PROTOCOL members) or structure (PCNET-DESIGN members) or actually write code for (PCNET-WORKERS members). As usual, if you don't have an account on an ITS system (thus can't use the INFO program directly) and you want one of the sub-frames pointed at by the menu items (lines starting with *), send me the menu item line and I'll MAIL you the frame it points at as soon as it has been written (yes, this is top-down structured document writing; first the main outline, then the lower-level stuff later!). File: PCNET, Node: New layer run-thru, Up: Protocol Suppose we have two computers on opposite ends of a telephone line, with modems to convert between binary and analog signals, and a UART to convert between octets of binary data and carefully-timed sequences of bits in real time. Thus either of the two computers can send an octet of data to the other which will be received it if no phone line noise interefered with the analog signals used to carry the data. Suppose we an application program on one of the two machines that wants to communicate to an application program on the other. It wants to be able to open several data channels (streams) to the other so it can send commands on one channel and data on another, or perhaps several kinds of data on different channels. It wants the receiving program to be able to distinguish data on the different channels, and it doesn't want the data to be damaged (deleted, duplicated, changed, rearranged, put on the wrong stream) en route. The receiving program doesn't want to hassle with bad data or temporary errors. It wants to receive exactly the correct data on exactly the correct stream, without being bothered by temporary error conditions that can be corrected, but it does want to be told if the communication link has completely broken down preventing further data transfer. The purpose of the lower&middle layers of PCNET protocol is to fill the gap between the needs of the application program and the services offered by the low-level software that drives the telephone-interface hardware, i.e. to insulate the application program from the error-prone telephone line and to provide the multiple streams and other facilities not available on a bare modem&UART link. Below are the various problems that exist in two application programs trying to communicate with each other, and the solutions provided by various micro-layers of PCNET protocol. (There are two major layers, the Link layer and the Directing layer. But the Link layer is subdivided into about six smaller layers called "micro-layers", while the Directing layer is subdivided into about two microlayers.) Menu: (Numbers 0 thru 7 indicate the sequence in which all these microlayers are stacked on top of each other when putting them all together to make the full PCNET protocol.) * 0-1 Interface:: Interface by which software can easily send and receive raw data on the modem&UART. This is what's provided by the hardware-level interface software and available to be used by PCNET-specific software. * 7-8 Interface:: Interface by which an application program sends and receives data on various streams. This is what the application program wants to see available for its use, instead of what's provided by the level 0-1 interface. motivation for each micro-layer, rearranged into teaching sequence... * 7str Motive:: How to multiplex multiple streams on one modem? * 7eod Motive:: How to detect end-of-file on a particular stream? Needs are satisfied by the Directing layer * 5 Motive:: How to make sure only good data gets through? Needs are satisfied by the Validating microlayer * 6 Motive:: How to retransmit when data didn't get through the first time? Needs are satisfied by the Sequencing microlayer * 2 Motive:: How to recognize start&end of a block of data on the line? How to assure that the UART will be correctly framed at the start of a block even if it was misframed from noise during the preceding block? Needs are satisfied by the packet framing microlayer * 1 Motive:: When genuine full-duplex operation is impossible, how to decide whose turn it is to speak without getting confused? Needs are satisfied by the half-duplex turnaround handshake microlayer * 3&4 Motive:: If data in the block conflicts with framing or half-duplex-turnaround characters, how to avoid confusing the two? What if the operating system doesn't allow 8-bit data to be sent/received? Needs are satisfied by the translating microlayer Summary, micro-layers put back into normal sequence as data feeds through each micro-layer to the next: Application program sits at the top, transmitting data downward and receiving data that arrives at the bottom and makes its way to the top. Application-level command to other program "PLEASE DO ACCEPT MAIL" Encoded as [8-bit opcode and binary arguments], on some stream. Sent down via a call to PWRITE. Received on other node via PREAD 7 Directing layer Block prefixed by header octet telling stream number and EOD bit. 6 Sequencing layer Data object has sequence number and acknowledgement number. 5 Validating layer Numbers packed into one octet, checksum or CRC in two octets, appended to the [directing octet & opcode octet & args] from above. Now have: [dir. octet & opcode octet & args & sequence octet & cksm] 3&4 Translating layers All data from just above translated into Radix-41, which doesn't include any characters that would conflict with framing atsigns or turnaround characters below, or data kept in binary as-is except characters that would conflict with framing/turnaround or with quoting mechanism are quoted. 2 Packet framing layer Each block now has atsigns around it to refreame the UART and to signal the start of each block. 1 Half-duplex turnaround handshake (Used only when in HDX software mode using FDX modems.) Nodes take turns sending one or more packets, sending trailing brackets, watching for lead-in atsigns from the other node within ten seconds sure it saw the turnaound (if not, retransmit turnaround and wait for atsigns again), then buffering up the other node's transmissions until receiving the trailing brackets from the other node, immediately sending leading atsigns to acknowledge turnaround, then processing the data that has been buffered and preparing the outgoing data to be sent as packets at the top of this loop. 0 Modem interface software UART/modem hardware sit at the bottom. (Well, actually the telephone line is at the VERY bottom.)  Date: 16 March 1983 13:31 EST From: Robert Elton Maas Subject: PCNET-DESIGN To: PCNET-PROTOCOL @ MIT-MC I'm going to be forming a new mailing list to discuss overall design aspects of PCNET and its software. This will not deal with protocol, that is agreements between machines as to the data exchanged between them and its meaning, thus I've decided not to use the PCNET-PROTOCOL list for this discussion, but since the people on PCNET-PROTOCOL are the ones most active currently (other than the workshop people, who have their hands full writing code), I'm sending this query here instead of to the general INFO-PCNET mailing list. Specific subjects to be discussed: How to maintain network directories telling NODE-IDs (which includes geographical location and phone number) and login JCL and modes available; How to organize the software for FTP1, MAIL1 etc. to permit all the modes of operation (interactive, unattended automatic) we've envisioned; ... Anyone wanting to be on this new list, contact me asap. I'll be presenting some "straw men" proposals for software organization within a few days.  Date: 14 March 1983 12:42 EST From: Robert Elton Maas Subject: Amended proposals (three of them) for image mode transfers To: PCNET-PROTOCOL @ MIT-MC Which of the following three proposals do you like? ---------------------------------------------------------------- FETCH-BINARY and STORE-BINARY (we might choose to call these FETCH-IMAGE and STORE-IMAGE to be more consistent with current teminology; after all binary is contrasted with decimal, whereas image is contrasted with text, and it's this latter distinction we want to make), would take an argument that tells the BYTESIZE. This must be a divisor of the wordsize on the source machine, or else we intend to discard the remaining bits in the word (after checking to make sure they are all zero). It must also be a divisor of the wordsize on the dstination machine, or else we intend to fill the remaining bits in the word with zeroes. If the BYTESIZE is 1, it's a special case, we mean to extract single bits from the words on the source machine and repack them into octets for transmission, then recover the bits from the octets and repack them into words on the destination machine. (This may actually be implemented in a more efficient manner, such as shifting by 8 bits for each octet and ORing together the two parts when a word boundary is crossed.) For all other BYTESIZEs the algorithm is defined as follows: (DEF) Let WORDSIZE1 be the word size on the source machine and WORDSIZE2 be the word size on the destinatin machine; (1) On the source machine, perform a LOSING-TRANSFORMATION (defined below), from WORDSIZE1 to BYTESIZE, obtaining a stream of bytes of size BYTESIZE; (2) Transmit as many octets as needed to send each BYTE, and set to zero the unused bits at the end of the group of octets for each BYTE; (3) On receipt, recover the BYTE from the group of octets; (4) Perform a GAINING-TRANSFORMATION (defined below) from BYTESIZE to WORDSIZE2. In a LOSING-TRANSFORMATION, you're trying to drop the extra bits (which must have been zero originally) if there's a mismatch between the two sizes. Thus a LOSING-TRANSFORMATION from size X to size Y is defined this way: - If X=Y then use the data as-is; - If X>Y then extract Y-bit bytes from an X-bit word, making sure the remainder were zero if Y isn't a divisor of X; - If XY then generate as many Y-bit words as it takes to hold an X-bit byte, setting to zero the remaining bits in the last word if Y isn't a divisor of X. For an extreme example, if you had a 17-bit machine and you wanted to store its files on some other machine and later get them back, you'd specify BYTESIZE as 17. Suppose you sent such a file from your 17-bit machine to a micro, thence to a PDP-10, and finally at a later time you downloade directly from the PDP-10 to your 17-bit machine. Here's how the repacking would go at each hop: 17 --> 8: WORDSIZE1=BYTESIZE=17 so the LOSING-TRANSFORMATION wouldn't lose any bits. 17 = 8*2+1 = 8*3-7, so three octets would be sent for each byte, wasting the last 7 bits in each such group-of-three-octets. Three octets would be gobbled to recover each 17-bit byte. Three octets would be stored for each 17-bit byte received. (The micro would never have to do these last two stages of repacking because the transmission size always equals the local word size.) 8 --> 36: WORDSIZE1=8, BYTESIZE=17, so the LOSING-TRANSFORMATION would have to gobble three words for each 17-bit byte, and make sure the last 7 bits in each group of three really are zero, lest it accidently be trying to send a file that didn't originally come from a 17-bit machine and lose bits due to this mistake. Three octets would be sent for each 17-bit byte. (A slight optimization could be done, the preceding step might not actually have to form 17-bit objects when checking groups of three 8-bit words for last-7-bits-zero, so this second step could just use the original 8-bit words as transmission octets. Three octets would be gobbled to recover each 17-bit byte. Since 17<36, bytes would be packed into one word, in this case two 17-bit bytes leaving 2 bits unused in each word. 36 --> 17: Since 17<36, 17-bit bytes would be extracted from each word, checking the remaining two bits in each word to make sure this was really a 17-bit-byte file rather than some random pdp-10 binary file. Three octets would be sent for each 17-bit byte. Three octets would be gobbled to recover each 17-bit byte. Since BYTESIZE=WORDSIZE=17, the GAINING-TRANSFORMATION would be trivial. To successfully transfer any binary file using this standard, you use the bytesize of the machine where the binary file was originally meaningful, except for when you want to define trans-machine bitstream file formats in which case you use BYTESIZE=1. ---------------- One remaining question. Do we define a particular ordering of bytes when packing, probably making it agree with PDP-10 ILDB/IDPB standards, thus making it compatible with Arpanet standards, thus guaranteeing that one could send a file 17-bit --(pcnet)-> pdp-10 --(Arpanet)-> vax --(pcnet)-> 17-bit and get all the data back again (but guaranteeing that the same triangle-journey wouldn't work if the middle hop were some non-arpa protocol that packed bytes in the other order)? Or do we leave the sequence of bytes in a word caveat emptor, thus not guaranteeing that even the pcnet-arpanet-pcnet triangle journey won't work, after we've gone to so much trouble to almost make it almost work? ---------------------------------------------------------------- Here's an alternate proposal... We don't define any standard for repacking bits at all, and we don't complicate the protocol by specifying a byte size. We let each program be different. The only requirement we impose is that when dropping bits the program must make sure they are all zero (if not, abort the transfer). Depending on the programmer, it may be possible to move 8-bit files via a 36-bit forwarding node, but not move 36-bit files without losing four bits of every 36-bit word (which at least warns the operator by aborting when this is attempted, unlike MODEM2 which just goes ahead and destroys the file); or it may be possible to move 36-bit files via 8-bit forwarding nodes but not vice versa; or both may be possible and work but be incompatible with MODEM2 and ARPANET; or binary mode might simply not be implemented on pdp-10s at all. ---------------------------------------------------------------- Here's yet another alternate proposal... We simply define three special cases, 8 bits 36 bits and repacking-binary, since 36 is the only non-multiple-of-8 that any reasonable machine ever has. Nodes wanting to forward pdp-10 files use 36-bit mode. Nodes wanting to forward all other kinds of machine-dependent files use 8-bit mode. Repacking-binary mode (my original proposal, which is case BYTESIZE=1 of the longwinded proposal at the start of this message) would be used for machine-independent bitstream files such as machine-independent data compression. Thus we'd have six commands: FETCH-8, FETCH-36, FETCH-BITS, STORE-8, STORE-36, STORE-BITS. Programmers could implement whatever subset they thought useful, and add more as the need arose. If there exists any machine with a 17-bit wordsize, it couldn't transfer its files via PCNET protocol without losing some bits.  Date: 14 March 1983 11:11 EST From: Robert Elton Maas Subject: binary mode standard To: GZ @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC Gee, maybe we'll have to go the full route of defining a byte size dynamically (at run time) instead of just having one "binary mode" that tries to transfer all the bits, or else have two modes one for saving all the bits and thus permitting bytesize-independent applications such as data-compression to be used as well as permitting bytesize-dependent transfers such as compiled object files to be transferred. Or maybe define a bytesize of 1 to mean repack all the bits and any other bytesize to mean optimize for that particular byte (word) size but don't ever split a byte (word) across an octet boundary?  Date: 14 March 1983 10:59 EST From: Gail Zacharias Subject: binary mode standard To: REM @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC In-reply-to: The message of 14 Mar 1983 10:41 EST from Robert Elton Maas On the other hand, if you store files with all 36 bits filled, you won't be able to PCNET-FTP a vax file to a PDP-10 and then ARPANET-FTP it to a vax. The reason you can lose either way is simply that the standard way of storing 8-bit bytes data on a 10 is different than the standard way of storing 36-bit bytes data. The way the Chaosnet deals with this is that a binary mode open has an extra parameter, BYTE-SIZE. When a PDP-10 server gets a request for a BYTE-SIZE 8 (or BYTE-SIZE 16) binary file, it uses the left-justified 32 bits/per word packing to fetch the "bytes" out of the words. Conceptually the Chaosnet channel is 16 bits wide, i.e. max BYTE-SIZE is 16. Hence PDP-10 files are transfered using BYTE-SIZE 12. This causes the server to use a 3-bytes-to-a-word packing, getting all the bits. That's what you get when you do :CFTP between MC and OZ for instance.  Date: 14 March 1983 10:41 EST From: Robert Elton Maas Subject: binary mode standard To: GZ @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC Addenda, with the standard you propose, it wouldn't even be possible to transfer binary files directly between two pdp-10 computers using PCNET protocol, because at the outset four bits of each word would be lost in unpacking 36-bit words into octets for transmission.  Date: 14 March 1983 10:36 EST From: Robert Elton Maas Subject: standard for binary mode? To: GZ @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC Gee, you seem to actually be encouraging PCNET implementors to use the "destroy four bits" standard when transferring pdp-10 files! That would mean one could never expect to transfer a data-compressed file from a pdp-10 thru a vax to another pdp-10 and get anything usable at the other end, not even if the programmers wanted to make that possible, because the standard would forbid implementing binary mode to keep all the bits and not lose four.  Date: 14 March 1983 09:43 EST From: Gail Zacharias Subject: standard for binary mode? To: REM @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC, RALPHW @ MIT-XX In-reply-to: The message of 14 Mar 1983 03:23 EST from Robert Elton Maas destination pdp-10. If we aren't careful in the specs, somebody might interpret our protocol to permit such non-conservative packing methods. Packing 4 bytes to a word is the *standard* way of storing 8-bit data on a PDP-10, for reasons that have to do with the PDP-10 architecture (i.e. if you know the instruction set, you know the reason). Filling all 36 bits, splitting bytes across word boundaries, would be highly non-standard and not handled by most software. E.g. you probably couldn't FTP (on the arpanet or chaosnet) such files to any non-10 sites. All the systems I am familiar with have some "standard" or "preferred" bit order, as determined by the machine architecture and manufacturer documentation etc. How about we just say the the data should be placed in the order standard on the given system. This would be 4 bytes per word, from left to right (i.e. 1st byte is in the high bits, last byte in the low) on the pdp-10. On a vax this would be 4 bytes per longword, right to left. And so on. Imposing some artificial global standard would make our software difficult to write and our files difficult to deal with on the host system.  Date: 14 March 1983 03:23 EST From: Robert Elton Maas Subject: Re: standard for binary mode? To: RALPHW @ MIT-XX cc: PCNET-PROTOCOL @ MIT-MC Date: 14 Mar 1983 0051-EST From: Ralph W. Hyre Jr. I DON'T UNDERSTAND THE PROBLEM OF TRANSPARENCY. AS LONG AS THE PACKING AND UNPACKING OF BINARY DATA IS CONSISTENT ON A GIVEN MACHINE, WHY ARE THERE PROBLEMS? FOR EXAMPLE, A 17 BIT MACHINE MIGHT PACK THE BINARY DATA IN SOME OBSCURE WAY. AS LONG AS UNPACKING RESTORED THE DATA RECEIVED TO ITS ORIGINAL STATE, THERE SHOULD BE NO PROBLEM. Indeed if there is only one version of the software on any given machine, and if every version at least saves all the bits in both directions (8->x and x-->8), what you say is true. But for example MODEM2 on PDP-10s packs four octets from the line into one 36-bit word, leaving four bits unused. When using a PDP-10 as a storage point between 8-bit two micros there's a slight storage inefficiency, but no loss of data. But when using an 8-bit machine (a VAX for example) as a storage point between two pdp-10s, those four bits would be discarded in going to the VAX and replaced by zeroes upon delivery to the destination pdp-10. If we aren't careful in the specs, somebody might interpret our protocol to permit such non-conservative packing methods. Furthermore, if two different vendors supply software for any machine, they might use different repacking algorithms, so that data moved to a second machine using one program can't be retrieved using the other. Thus when archiving data, a complete backtrace of what programs it passed through must be kept to be assured of being able to bring the file back in its original form. Also if a vendor changes the repacking algorithm when it brings out a new version of a program, suddenly all old files stored on other machines with different word size become unrecoverable. I think to prevent all these sorts of problems we ought to specify the repacking sequence at the start.  Date: 13 March 1983 19:36 EST From: Robert Elton Maas Subject: opcodes for FTP1, need vote/concensus on this decision To: SIRBU @ MIT-MC cc: PCNET-PROTOCOL @ MIT-MC I think you misunderstood proposal (1) slightly. There is no dividing of address space according to class of opcode (official or ad hoc), no address space is reserved for ad hoc opcodes. Ad hoc opcodes are just stuck on the end of the official ones. Each time an official one is added, it steps on an ad hoc opcode that must then be moved elsewhere. If the official opcode list never changes, this is the most efficient method, because a single table lookup can catch both ad hoc and official opcodes in one gulp. But each time a new official opcode is added it wreaks havoc on anyone using ad hoc opcodes. Thus I think you dismissed that proposal for a wrong reason.  Date: 13 March 1983 17:22 EST From: "Marvin A. Sirbu, Jr." Subject: opcodes for FTP1, need vote/concensus on this decision To: REM @ MIT-ML cc: PCNET-PROTOCOL @ MIT-MC I vote for proposal number 2. Proposal number one amounts to setting the high order bit to zero for official op codes and to one for ad hoc op codes. That allocates too much op code space to ad hoc op codes. Proposal 2 provides for a single tabel for official op codes without pre-allocating the amount of op code space for ad hoc versus official. Marvin Sirbu  REM@MIT-ML 03/13/83 03:13:37 Re: How to transfer part of a file? To: PCNET-PROTOCOL at MIT-MC Ok, I've finished looking thru PCNET;FTP1 PRO, the proposed protocol for direct end-to-end non-forwarding data (file&mail) transfer. There's one remaining major topic to discuss/consider. How to transfer part (instead of all) of a file? Local files are easy. You use an editor to select the window you want to send, or to put the cursor at the spot where you want the incoming text to be deposited. It doesn't have anything to do with protocol. But suppose you want to fetch part of a remote file, or deposit data at some place in a remote file? How do you communicate to the other machine what part of a file you are referring to? (By physical location, i.e. n bits from the start? By a search string?) What if the file is structured, such as NLS or INFO, or an ISAM database? This would be a really useful function if we could figure out how to do it via protocol. Do we want to include this in FTP1 protocol? If so, how? Do we want to include append (deposit at end, making the file larger) and prepend (deposit at start, shoving the rest of the data back), but leave out the general case?  REM@MIT-ML 03/13/83 02:51:17 Re: standard for binary mode? To: PCNET-PROTOCOL at MIT-MC There are two major ways to define binary mode: (1) Caveat emptor; if both machines have 8-bit words, then words and bytes are the same, and PCNET transfer of data in binary mode is transparent; But if any machine has any word size other than 8 bits (for example 16 on a pdp-11 or 68000, 36 on a pdp-10, 32 on an IBM 360, 24 on a Four-Phase IV/70, etc.), then the packing of bytes into words may be defined in any damn way the programmer wants, thus if the two PCNET programs were written by different people it's impossible to assure that data can be correctly transferred between two machines either of which is of non-8-bit wordsize, nor to forward a file thru a non-8-bit wordsize machine on behalf of two 8-bit machines that are original source and final recipient of the file. (2) Defined bit sequence; we define a sequence of bits within bytes that are transmitted by PCNET, and also a sequence of bits within words on the two machines; When an 8-bit machine is sending or receiving a file, the bit sequence is achieved by simply sending the 8-bit bytes in sequence, no repacking is needed; When a machine with a multiple of 8 bits is used, our bit-sequence standard implies a particular sequence of packing bytes into words, and all programers must obey that packing standard, but no ugly stuff like reversing bits is ever needed; When a machine with a word size that is not a multiple of 8 is used, repacking of bits where some bytes come from parts of two different words occurs, and we specify the repacking pattern. In all cases, if the original source of a file and the final recipient of a file have the same word size, even if inbetween several relay machines had different word sizes, the file will still be delivered with the bits in exactly the same place in the same word as they started, thus binary files can be transferred. Some data formats such as compressed data may be defined directly in terms of our bit sequence, and be valid on machines with different word sizes, although in the usual case the relay machines with different word sizes will find the data meaningless but will nevertheless be able to forward it to a machine where the word size will be correct and the file will be meaningless. Somebody else has proposed the first option (caveat emptor) but I am strongly in favor of the second option (specified bit sequence), and would like at this time to obtain a concensus to agree with me on that point.  REM@MIT-ML 03/13/83 02:34:37 Re: opcodes for FTP1, need vote/concensus on this decision To: pcnet-protocol at MIT-MC Although this isn't as important as the large scale design questions, it's more like a petty detail, still we have to come to some decision before we release this document, and since Fylstra has proposed an alternative to my system perhaps we ought to decide which convention to use. I won't say who proposed which of these so just consider their merit: (1) Put all opcodes, official and ad hoc, at the start of the address space. BYE, SEND-BINARY, RCV-BINARY, ... HELP, foo, baz, ... (2) Put official opcodes, both functional and help, at the start of the address space. Put ad hoc experimental opcodes at the end. BYE, SEND-BINARY, RCV-BINARY, ... HELP, ... baz, foo. (3) Put official functional opcodes at the start, and help opcodes at the end. Put ad hoc opcodes in the middle. BYE, SEND-BINARY, RCV-BINARY, ... ... HELP (4) Divide opcode space into sections and put different types of opcodes in different sections. (5) Other? Option (1) has the advantage that a single indexing into a table can decode an opcode instead of two or more. It has the disadvantage that everything's lumped together with no rhyme or reason, and that when new official opcodes are added it dislodges experimental opcodes. Does anybody have any other reasons for one method or another, or shall I call for a vote or concensus?  Date: 13 March 1983 01:45 EST From: Robert Elton Maas Subject: Other important issues we've neglected To: PCNET-PROTOCOL @ MIT-MC I chatted with Dave Fylstra on the phone and we sort of agreed there are several aspects of the total PCNET system that we've been neglecting and we ought to consider rather soon: Of course we need to finish the FTP1 protocol we were drafting last November. I'll look thru the current proposal, clean up anything that is in a bad state, and then resubmit it to this forum for comment. In the past we've been concerned with the protocol to be used over the modem, i.e. the low-level protocols, the application program protocols, and the header format for electronic mail. We decided long ago to leave issues of user interface and programming methods to the individual implementors. I've tried to suggest ways of doing the software, but neither I nor anybody else has tried to set up a programming standard to which everyone must adhere as they MUST adhere to protocol in order to talk to other nodes. But we haven't even proposed an example of how to put the whole thing together: how to keep track of other nodes, how to keep a schedule of events such as sending mail at 11pm and how to use that schedule to actually perform events at the correct time, how to fit together the mail-editor and the PCNET mail-delivery system, ... Perhaps it's time we did create such a model overall PCNET configuration. To compete with MODEM2 we must create a model system that can easily do useful things MODEM2 can't ever do, really do them not just be expandable into doing them. -- As time permits I plan to write a "straw man" proposal for everybody to criticize and improve upon. There are also a couple points about activating application programs and allocating streams that aren't sufficiently explained in PCNET;APPPRG PRO. I plan to fix up that document. Our software should permit: (1) Issuing commands or queuing events/tasks while offline, having the PCNET program automatically connect, do the task, and disconnect when done (our original design); (2) Manually connecting and talking to the other host for a while, then escaping from talk mode to enter PCNET protocol without having to disconnect and redial (like MODEM2); (3) Same as 2 but using error-controlled TELNET protocol instead of direct modem-to-modem talk, and inside TELNET escaping from text mode to issue a local command that causes FTP or other task to be invoked inside TELNET (stacking of application programs), then revert to TELNET protocol when done. Most of this flexibility is obtained in two ways: (a) Making the HELLO utility so that if already connected it just enters protocol instead of redialing; (b) changing the directing layer to accept node-control messages even while an application is "in control", intercepting these node-control messages instead of passing them up to the pending PREAD, stacking application programs as requested. These were always options in advanced implementations (probaly not for SIMPLE mode), but now it appears we may want to include them in the very first major version we release. I'd like to encourage discussion on all these topics, as well as what we were discussing before.  Date: 11 March 1983 13:33 EST From: Robert Elton Maas Subject: Ready to resume work? To: PCNET-PROTOCOL @ MIT-MC Are enough of you back on the net with TCP that we can get back to thrashing out the design of the FTP1 application program protocol?  Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 02-Mar-1983 02:47:43-est Date: 1 March 1983 2343-mst From: Paul Schauble Subject: faster than 300 baud To: PCNET-PROTOCOL @ MIT-MC I agree that considering 1200 baud modems is a good idea. It is now generally possible to get manual 212A style modems for well under $500 and an auto-dial unit for just over $500. Considering that a new 300 baud modem will go for ~$150 manual and ~$250 auto-dial, one could save the difference in line charges before too long. Be aware, however, that the 212 line protocol is very different from what the 103 (300 baud) modems use. In particular, the 212 is really a synchronous modem with async to sync converters built in. Unlike the 103 style, which can run any bit rate up to 300, the 212 must run at exactly 1200. Also, none of the 212 modems I have ever seen are able to switch speeds during a call. The line speed used will be established by the originating modem, either by switch or by an interface pin. This selection will be communicated to the remote (called) modem as the two establish synchronization. The called modem will inform its computer by interfact pin. So the called computer should look at the interface to determine the speed of the incoming call. If it cannot do this, but can control the speed of the UART, it is possible to examine the first character that comes in and determine the speed. More information on request. If you cannot either test the interface or change the UART speeds, you have to pick a speed and let it be fixed. Paul  Return-Path: <@MIT-MULTICS.ARPA:Schauble@M.PCO.LISD.HIS> Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 02-Mar-1983 02:47:43-est Date: 1 March 1983 2343-mst From: Paul Schauble Subject: faster than 300 baud To: PCNET-PROTOCOL @ MIT-MC I agree that considering 1200 baud modems is a good idea. It is now generally possible to get manual 212A style modems for well under $500 and an auto-dial unit for just over $500. Considering that a new 300 baud modem will go for ~$150 manual and ~$250 auto-dial, one could save the difference in line charges before too long. Be aware, however, that the 212 line protocol is very different from what the 103 (300 baud) modems use. In particular, the 212 is really a synchronous modem with async to sync converters built in. Unlike the 103 style, which can run any bit rate up to 300, the 212 must run at exactly 1200. Also, none of the 212 modems I have ever seen are able to switch speeds during a call. The line speed used will be established by the originating modem, either by switch or by an interface pin. This selection will be communicated to the remote (called) modem as the two establish synchronization. The called modem will inform its computer by interfact pin. So the called computer should look at the interface to determine the speed of the incoming call. If it cannot do this, but can control the speed of the UART, it is possible to examine the first character that comes in and determine the speed. More information on request. If you cannot either test the interface or change the UART speeds, you have to pick a speed and let it be fixed. Paul  Date: 1 Mar 1983 0038-PST Sender: BILLW at SRI-KL Subject: Re: faster than 300-baud From: BILLW at SRI-KL To: REM at MIT-MC Cc: PCNET-PROTOCOL at MIT-MC Message-ID: <[SRI-KL] 1-Mar-83 00:38:39.BILLW> In-Reply-To: Your message of 28 February 1983 22:48 EST I dont think it will work. AS far as I know, none of the current dual or triple protocol modems will actually swicth protocols in the middle of a connection. Personally I feel that the modem should figure out what the protocol is, and then to some kind of auto-bauding... Bill W  Date: 28 February 1983 22:48 EST From: Robert Elton Maas Subject: faster than 300-baud To: PCNET-PROTOCOL @ MIT-MC Date: 28 Feb 1983 1439-EST From: Ralph W. Hyre Jr. There is a HELLO (ICP) option for starting right off at a higher than 300-baud standard speed (600 baud is our current plan) Wouldn't a 1200 baud default higher speed be better, since there are lots of 1200 baud Smartmodem-type modems around now? The original reason we added a high-speed option to the HELLO negotiation was that some Bell 103 modems such as the PMMI are capable of running at up to 600 baud. We avoided specifying a 1200-baud option because at that time different modems had to be used for Bell 212 or 202 from Bell 103. But now that combined modems capable of both Bell 103 and some higher speed exist, which can switch modes without losing the connection, perhaps we should now define a HELLO option for switching from 300 baud to 1200 baud? Do the rest of you think it would be worthwhile at this time? If so, anybody care to take the time to look at the existing HELLO protocol (I'll be bringing it online again in the next few days) and propose a way to include the 1200-baud option?  REM@MIT-ML 12/21/82 02:24:33 Re: MODEM2&7 competition To: PCNET-PROTOCOL at MIT-MC It occurs to me that if we are rushing to install interactive FTP mode in PCNET protocol before release, in order to directly compete with MODEM2, we ought to make the user interface for the originate-mode FTP user program virtually identical to the MODEM2 user interface so that users can try our program without having to learn anything new beyond how to start up our program and what nodes they can call with it. I propose we obtain the user manual for MODEM2 (I think it's on MIT-MC but that host is down for TCP debugging, I'll check later), then find somebody with MODEM2 and MODEM7 and try out the programs to verify the manual is correct and to fill in what prompts the program issues that the manual may not say exactly, and create an updated online user manual that specifies the user interface well enough for a programmer to emulate it. Then I can write my FTP user interface in my LISP program accordingly, and you-all can write your C and PASCAL FTP user-program interfaces accordingly, and they can all be user-plug compatible with MODEM2&7. Feedback on this idea? Volunteers to try MODEM2 & 7 on their machines to get the details we need? I'll volunteer to merge a marked listing into the online file to create a first draft of a user-interface spec, and to upgrade my LISP FTP user interface facade after TCP is up next year.  Date: 18 December 1982 23:24-EST From: Robert Elton Maas Subject: Files going away To: PCNET-PROTOCOL at MIT-MC I've been moving files from MIT-MC to SU-AI in preparation for the big TCP switchover, so that in the event either host is off the net for a long time I'll still be able to make listings of my files. I've kept REM;FTP1 PRO around until the last because several people were actively discussing it, but activity seems to have died down in recent weeks so I figure this is a good time to move it. I'll also move FTP UA which I was planning to develop into preliminary suggestions for a User Agent but never got around to and won't now. I moved the source for my LISP PCNET server a couple weeks ago, but kept the object program here in case anybody needed a test node to play with. I'll keep it in that state, working test node but no bugs will be fixed because the source is inconvenient to access at this time. I'm looking forward to another burst of protocol activity after the Arpanet is back up with TCP at all our favorite hosts in 1983. Until then, happy new year.  Date: 15 December 1982 00:22-EST From: Devon S. McCullough Subject: packet SWITCHING obsolete To: REM at MIT-MC cc: PCNET-PROTOCOL at MIT-MC, PROTOCOLS at MIT-MC Well, TymNet is not nearly as robust as ARPAnet - when a TymNet link goes down, you lose your connection and some amount of data (this may have been fixed) wheras ARPAnet just happily re-routes your stuff. I suspect TymNet still comes out ahead since that is presumably rare. TymNet reduced switching overhead by allocating fixed packet buffers in each node when a stream is created. I don't see why ten streams represents any more overhead than one stream with nine sub-streams???  Date: 12 December 1982 09:59-EST From: Robert Elton Maas Subject: packet SWITCHING obsolete To: PROTOCOLS at MIT-MC, PCNET-PROTOCOL at MIT-MC I have long though that in most cases packet switching, that is passing a packet with a full network address inside it from one node to a second and then switching it to yet a third etc. until it finally reaches its addresee at which the packet is decomposed (the data part extracted) is not the way to go; rather simple exchange of packets between adjacent nodes, with no long addreses, immediate decomposition, and sticking the data part into a new packet for the next hop, was the way to go. Single bytes can be sent efficiently because there are only a few bytes of header&checksum&streamnumber with such a method, primarily because the node address of the destination has to be specified only once when setting up the stream instead of inside every packet. But I have thought that maybe in some cases packet switching may actually be optimal. For example if there's a lot of traffic along different logical streams between two non-adjacent nodes it would seem to be inefficient to allocate many logical streams that have to be decomposed and recoposed at each hop along the way. Better to bundle all those streams at the source end into one subnet connection and send them all in large packet to be decoposed into individual logical streams at the destination instead of requiring each relay node to handle all the streams separately. Well, this morning I came up with an idea. Use bundles of streams as if they were single streams. In practice, if a relay node notices it has several different streams that all come in from the same neighbor and all go out the same other neighbor, it negotiates with those neighbors to make a bundle out of the streams. If later it gets a request to open a new stream along the same two hops, it creates a new element of the bundle instead of creating a new individual stream. At either end of a bundle if it's noticed that most (or all) of the members of the bundle make the same next (or preceding) hop, the bundle is extended along that hop. Thus a bundle extends until it goes all the way from where the several different streams first come together (perhaps at their very start) to where they first diverge (perhaps at their final destination). It's logically consistent to have bundles of bundles of streams in cases where several bundles converge and follow a common multihop path then diverge. Bundling can be to any depth although depth exceeding one should be rare in practie. I don't know if the extra complication of handling the general case would be worthwhile. I think that packet exchange (not switching), allocating streams until either the stream is closed or a relay goes down and it needs rerouting (or a hop gets overloaded so rerouting is desired), rather than dynamically switching every teensy packet as Arpanet does, is the way. I think bundling of streams as described above (with or without nested=recursive bundling) makes this workable&efficient in all cases, achieving much higher efficiency than packet switching when many streams sharing common routes are engaged in single-byte and small-block interactions. I welcome any rebuttal to my thesis.  Date: 25 November 1982 05:44-EST From: Robert Elton Maas Subject: FTP1: master vs slave To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC Date: 19 Nov 1982 at 1729-PST From: fylstra.tsca at SRI-Unix Regarding who takes role of protocol master in PCNET... In simple mode we assume (1) the I/O may possibly be crufty, such as a large timesharing system that can't do 8-bit I/O, a network connection (Arpanet, Tymnet, Telenet, etc.) that has various reserved characters and/or 7-bit restriction and furthermore may be implicitly half-duplex, or a micro without interrupts that can't do full-duplex without a *MAJOR* programming effort beyond the capability of our volunteer group and most independent volunteer programmers; (2) the software system is capable of subroutines but not co-routines or interrupt-handling or multi-tasking or timesharing; (3) the available mainframe memory may be quite small (we originally envisioned 4k RAM plus BASIC interpretor but now we see we need at least 8k and more likely 16k, but even so that rapidly gets cramped using anything except machine/assembly language) which may require writing separate core load modules for answer-slave, originate-MAIL-master, and originate-FTP-master. -- PCNET simple mode tries to be the lowest common denominator for all such nodes, so that we can establish a network where any two nodes with matching modems can talk to each other even if everything else is wrong between them. Non-simple modes are preferred whenever two nodes have established a-priori that they can both handle a non-simple mode, but simple mode remains as a last resort assurded of working when all other nodes fail. Thus PCNET tries to be a WordNet instead of just one more private network that 90% of the computers can't join for various reasons. Our choice of 300-baud Bell-103 as the default modem speed&type is for the same reason. Regarding high-level protocols, our task therefore is to design protocols that will give full usefulness/functionality with the full PCNET lower layers yet be usable (probably some subset thereof) with PCNET simple mode lower layers to accomplish the major objectives of a WorldNet. To simplify the programming, we assume the application program calls PREAD and PWRITE as subroutines, and whatever that comes back MUST be returned to the application program that made the call rather than to some other process that might be running on a multi-tasking system. On the originate node, the application program running initially will be either FTP or MAIL itself or else a toplevel that calls FTP or MAIL rather soon. After node IDs are exchanged the FTP or MAIL program is surely in control. It first asks for the FTP1 or MAIL1 slave on the other node, then talks to it. On the answer node, the application program running initially will be the toplevel slave, which calls PREAD expecting (after node IDs are exchanged) to receive a control message requesting the FTP1 or MAIL1 or ECHO slave (server). The toplevel slave then calls the requested slave as a subroutine, which returns (to the toplevel slave) when all done. During the time the specific slave is being run, there's no way to get back to the toplevel slave, and since many programming languages don't have re-entrant (recursive) subroutines the specific application program can't call another incarnation of the toplevel slave from inside the specific slave while the original incarnation of the toplevel slave is still pending. This is why unsolicited control messages, in particular requests for additional specific slaves, aren't allowed in simple mode. Since the same is true on the originate node, namely that inside the originate (master) FTP or MAIL program it's difficult to allow for handling unsolicited control messages (such as the ANSWER node asking for a slave to be started on the ORIGINATE node deep inside the execution of the originate-master-FTP or -MAIL program), and it's unlikely anyway that deep inside the specific slave program on the answer node that such a request would be generated, at least in simple mode. -- Note that with careful programming in LISP or Algol or other language with resursive subroutines it may in fact be possible or even not very difficult to allow for unsolicited control messages an even stacking of application programs. But that isn't the common denominator of BASIC, FORTRAN, et al, so it isn't simple mode. Within an application program suh as FTP or MAIL the same arguments arise but to a lesser extent. It's probably quite difficult to support simultaneous file-transfer in both directions within one application program, although some good programmer might work it out since it doesn't impact the rest of the PCNET software like starting up multiple application programs would. On the other hand it's not too hard at all for the master and slave application programs to switch roles by agreement. One way to do this is for the master program to say "I'm all done wth what I had in mind, now it's your turn to suggest things to do", and then the former-slave program to either say "I'm done too, exiting now" or else to take the role of master for a while. Only the toplevel command handler in the mostly-master (originate) and mostly-slave (answer) application programs are affected by this role-reversal possibility, not the internal workings for handling the various tasks that might be requested. Given all that, and given that people with originate-only modems on their personal computer might want to be able to receive as well as send mail, we have several ways to do it: (1) dial the number but use reversed carrier and reversed protocol accordingly , (2) dial the number and give node ID then explicitly ask roles to be reversed at the top level of PCNET , (3) allow both nodes to initiate requests for application-program slaves , (4) allow only originate to request slaves but allow slaves to take master role after done with slave role , (5) add more protocol so that receiving mail can be done directly, initiated by the receiver rather than by giving node ID and waiting for the sender to initiate it . Thus in summary, the protocol allows for role-reversal within an application program, handling unsolicited control messages, stacking application programs, even having several application programs active simultaneously and interleaving data from them in real time; but simple mode has none of these enhancements and implements only a small subset of options within each application program and only a teensy subset of node-control options, while slightly-better-than-simple has only role-reversal within application programs and perhaps a slightly larger set of options. Furthermore simple mode doesn't have code for handling node-control messages that negotiate to improve performance, such as changing baud rate leaving Radix-41 mode, nor for formally and cleanly rejecting unexpected illegal requests such as unsolicited control messages. (In simple mode it's acceptable to just hang up the phone immediately upon receiving a node-control message or any other communication along an unexpected logical stream, whereas enhanced mode software is expected to handle illegal options in some more reasonable way, like sending back a "I-Won't Change-Baudrate" in reply to a "Please-Do Change-Baudrate" that arrives right in the midst of expecting a PREAD to return with more data of a file that is in transit.) Your paragraph listing about seven restrictions that simple mode has is pretty complete (you asked me not to repeat *any* text of your message so I won't). I hope the above will give motivation for these restrictions in simple mode. You say you'll make your CP/M implementation fully symmetric. That's fine, just be sure when it's talking to a simple-mode implementation that it doesn't try sending node-control messages right in the middle of running an application program, and that the answer node doesn't try to ask the originate node to start up application-slave programs. Of course when talking to non-simple nodes you're free to try everything unless the other node is paying for the call and doesn't want your node wasting its money asking it for random options when it still hasn't had a chance to do what it called you for.  Date: 19 Nov 1982 at 1729-PST To: pcnet-protocol at Mit-Mc Cc: fylstra.tsca at SRI-Unix Subject: FTP1: master vs slave From: fylstra.tsca at SRI-Unix Via: Sri-Tsca; 19 Nov 82 17:33-PST REM's elaboration of QRU raises an issue that has been lurking at the back of my mind for some time now. There seems to be an implicit assumption (apparently not yet documented in PCNet writings) that the originate node takes the role of protocol master and the answer node takes the role of slave. I have heard mention of a possible role reversal once the master has accomplished everything he set out to do. This is reasonable in light of the fact that is the originator's dime that is financing the call. It may also simplify the implementation. There is also mention in PCNet writings of "simple" vs "advanced" vs "ethyl supreme" (or whatever it is called) modes of operation. Until recently I had been thinking that "simple" mode just involves Radix-41 encoding, half-duplex operation, and one packet outstanding at any given time. Now it appears that "simple" mode also includes (1) only one node can request application activation at any time (i.e. one node is always master); (2) only one application can be alive at any given moment; and (3) non-application messages (such as control-sream messages) are not allowed when the application is active. The question, then, is just what restrictions are made upon the serving layer when in "simple" mode? We are considering making our CP/M implementation fully symmetric without any master/slave distinction. For example, one can imagine the two users simultaneously sitting at their respective interactive FTP1 user interfaces requesting directories and file transfers of the other end's file system. This obviously complicates the design of the serving layer, in that one must be prepared to accept and dispatch requests on any incoming or outgoing logical stream. This kind of thing is most properly handled by a multiprogramming operating system, but it can be simulated by dispatching to finite state machines. Mark Gang took this approach in his Pascal Transfer Program, which managed to multiplex file transfers with terminal chatting. Dave Fylstra  Date: 19 Nov 1982 at 0906-PST To: fylstra.tsca at SRI-Unix Cc: pcnet-protocol at Mit-Mc Subject: Re: FTP1 addenda In-reply-to: Your message of 17 Nov 1982 at 1527-PST. From: chesley.tsca at SRI-Unix Via: Sri-Tsca; 19 Nov 82 9:10-PST But we went on after that suggestion to consider one very like REM's proposal for final ACK: The end-of-data mark is an implied Please Do Accept the File, which is answered by either I Will or I Won't. In addition, at any point in the transfer, the receiver can say I Won't Accept the File (due to out-of-space, operator abort, etc.). The sender should then immediately send the end of data mark to complete the abort. Dumber implementations have the option, tho, of ignoring the control stream (I mean FTP control, not abs control) until done; then when they send the final, implied Please Do Accept, the I Won't Accept will already be there waiting. (If you want to allow a reply to the I Will Accept/I Won't Accept, in order to maintain consistency, we can just say that that reply is ignored.) --Harry... P.S. This was composed yesterday, but got delayed because I was working at home and the Tymnet link went down. I'm sending it on before reading the continuing discussion, so I hope it isn't out of date.  Date: 18 Nov 1982 at 0939-PST To: fylstra.tsca at SRI-Unix Cc: pcnet-protocol at Mit-Mc Subject: Re: FTP1 addenda In-reply-to: Your message of 17 Nov 1982 at 1527-PST. From: chesley.tsca at SRI-Unix Via: Sri-Tsca; 19 Nov 82 3:45-PST But we went on after that suggestion to consider one very like REM's proposal for final ACK: The end-of-data mark is an implied Please Do Accept the File, which is answered by either I Will or I Won't. In addition, at any point in the transfer, the receiver can say I Won't Accept the File (due to out-of-space, operator abort, etc.). The sender should then immediately send the end of data mark to complete the abort. Dumber implementations have the option, tho, of ignoring the control stream (I mean FTP control, not abs control) until done; then when they send the final, implied Please Do Accept, the I Won't Accept will already be there waiting. (If you want to allow a reply to the I Will Accept/I Won't Accept, in order to maintain consistency, we can just say that that reply is ignored.) --Harry...  Date: 18 November 1982 11:15-EST From: Robert Elton Maas Subject: FTP user-program interface To: PCNET-PROTOCOL at MIT-MC For those of you concerned about the user interface, I've finished writing the first version of the FTP user interface for my LISP program. Log into MIT-MC, load my LISP environment by saying :LISP REM;REM LISP then say (REMLOAD 'PCNSR6) to load in the PCNET software then say (O8FTP) to start the FTP user-interface. An alternate way is to load the PCNET LISP environment either by logging in as PCNET (password FREE) or to log in as yourself and say :LISP REM;PCNET LISP then after it starts running answer mode server you abort with ctrl-G and say (O8FTP). It's designed for a glass tty, i.e. a CRT that is emulating a printing terminal, or for a real printing terminal. More fancy interfaces can be designed for full display terminals that use windows and cursor, but I'll leave that for somebody else. My method is simple and easy to implement and good enough to get by. Currently it's a facade, only pretends to actually transfer files, because the FTP1 protocol hasn't finished being designed yet. P.s. "O8FTP" means Originate mode, level 8 (application programs), file-transfer-program.  Date: 17 Nov 1982 2152-PST Sender: BILLW at SRI-KL Subject: Re: FTP1 addenda CHANGE-WORKING-DIRECTORY From: BILLW at SRI-KL To: REM at MIT-MC Cc: fylstra.tsca at SRI-UNIX, PCNET-PROTOCOL at MIT-MC Message-ID: <[SRI-KL]17-Nov-82 21:52:25.BILLW> In-Reply-To: Your message of 17 November 1982 19:50-EST The difference between LOGIN and CHANGE-DIRECTORY is that LOGIN give you the group rights of the directory you are accessing. The owner/group/other method of file protection is not yet very common on micros, but is widely implemented on larger computers. A typical example would be that CHANGE-DIRECTORY would not necessarily allow you to write files in the directory, whereas LOGIN would. This is the way that tops-20 works for example, although ARPA TOPS-20 also distinguishes between using a directory as a default and actually connecing to it. BillW  Date: 17 November 1982 22:17-EST From: Robert Elton Maas To: PCNET-PROTOCOL at MIT-MC I've done another edit to REM;FTP1 PRO. I've specified proposed arguments for some of the commands and replies. Most notably, both expected/allowed sizes and file (path) names are included. Otherwise I've just cleaned up some things and flagged the required commands. Question, should the short form of help (list of command codes), or the long form (verbose text documentation of available commands), or both, be REQUIRED? The short form makes it easy for nodes to compile a table of what's available without having to actually try each one, while the long form is nicer for humans but takes a lot of space which might not be available.  Date: 17 November 1982 20:25-EST From: Robert Elton Maas Subject: FTP1 addenda -- ack of file safely stored To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC The interim mail protcol used "GOOD:..." and "BAD:..." on the second or third stream in reverse direction to acknowledge the file (message in this case) had been safely stored and queued for forwarding or to warn about some condition that might lose the file (message) such as bad header or disk full or operator wants to use the computer etc. I adopted that method in MAIL1 and tentatively specified it in FTP1 PRO. I'm willing to consider alternate ideas if there's a concensus for the alternative. GOOD/BAD replies have the advantage that they're automatic and don't require the sending node to do anything beyond setting the END-OF-STREAM bit on the last block of the file, but have the disvantage that they require more parsing than a one-byte binary code would. Sending a "BAD:..." while a file is still being sent could be defined as an abort signal. -- Here's a compromise i'd like to suggest: Have the "I-Will ack-eof" and "I-Won't ack-eof" messages as you suggest, but generate them automatically at the end of the data instead of first requiring a "Please-Do ack-eof" message. After all, there's nothing in the 4-way system (Please/I do/don't) to require a Please before any I, in fact we explicitly say that upon receipt of an unsolicited I-Will with an opcode that isn't known a Please-Don't is supposed to be sent back, so unsolicited "I-Wills" are certainly reasonable to have in the protocol. On the other hand, we sort of assume that both a Please-Do and an I-Will are needed to handshake, even if the order of them isn't critical, thus the I-Will will probably have to be sent anyway so the bandwidth will be eaten anyway. Anyway, let's have some debate on the end-of-file safely-stored acknowledgement method... (Gee, I'm glad I haven't starting writing LISP code for FTP1 protocol yet!)  Date: 17 November 1982 20:12-EST From: Robert Elton Maas Subject: FTP1 addenda -- required vs. optional To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC Making the REQUIRED functions be low-numbered ones, for ease in making dispatch tables, makes sense in the PCNET context (volunteer labor on tiny machines). What I'll do is flag the ones we think we should be required (the four you specified unless we change our mind), and after this decision is stable I'll edit the table to move everything around to make the flagged ones numbered 1 thru n (or 0 thru n-1? I sort of prefer to leave 0 available for escape prefix or emergency addition of new required command; what do you think?). Ok? We should probably go back and do the same with the MAIL1 protocol. Since I wrote the original specs I guess I volunteer to do the edit and then post it for comment before making any changes to my LISP program that implements it as it is now.  Date: 17 November 1982 20:06-EST From: Robert Elton Maas Subject: FTP1 addenda To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC The idea of QRU (I'm done, are you?) instead of EXIT (I'm done, and I won't let you do anything at all!!) is that sometimes node 1 calls node 2 and starts up the FTP1 server but node 2 has a file it wants to send to node 1 or fetch from node 1. Node 1 says "I'm done, now your turn, or confirm you're done too" via the QRU message. This was done in MAIL1 (derived from GNU's interim mail protocol) and it seems reasonable here too. It's especially needed in the case when a node has no dialout capability but it wants to initiate requests for file transfer on behalf of somebody else. In simple mode the answer node can't ask to start up the FTP1 protocol, but after the originate node has requested FTP1 protocol and requested all the files it wanted and given the QRU request, the answer node can request a file to be transferred before acknowledging the QRU.  Date: 17 November 1982 19:56-EST From: Robert Elton Maas Subject: FTP1 addenda -- or delimiter? To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC Since all the transparency we set up at lower levels allows 8-bit codes to be sent between application programs, and PREAD/PWRITE are required to handle these 8-bit data, can you tell me why you prefer usurping as a delimiter instead of using + (hex 80) or + (hex FF) as the delimiter, with space parity used for all filenames on all reasonable systems? I think one of the mark parity characters will be easier to test for as well as not usurping one of the 7-bit ASCII characters for the delimiter. (I'd like to hear your arguments in favor of usurping space parity as the delimiter.)  Date: 17 November 1982 19:50-EST From: Robert Elton Maas Subject: FTP1 addenda CHANGE-WORKING-DIRECTORY To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC There seems to be a subtle distinction between LOGIN (when already logged in, which changes the account&directory, and needs a password on most systems), and CHANGE-WORKING-DIRECTORY (when already logged in, which merely changes the directory without giving a password). I'm not sure exactly what the distinction is really. Do we really need both capabilities? (This is not a rhetorical/satiracal question, I really don't quite know. Since the directory can be specified in the filename string anyway, and since CHANGE-WORKING-DIRECTORY merely changes the default directory when none is supplied, it would seem to be merely a convenience for the human, and thus belong in the USER-INTERFACE instead of in the node-to-node FTP1 protocol, but maybe there's a good reason for having two different ways to specify a directory, by specifying in each filenamestring, or by setting it as default and then not specifying in filnamestring?)  Date: 17 Nov 1982 at 1527-PST To: pcnet-protocol at Mit-Mc Cc: fylstra.tsca at SRI-Unix Subject: FTP1 addenda From: fylstra.tsca at SRI-Unix Via: Sri-Tsca; 17 Nov 82 15:38-PST I am pleased with the general direction the FTP1 design is taking; there are a few additional details that need discussion: 1. I agree with REM's idea to bundle arguments into one packet when a command takes more than one, e.g. RENAME-FILE. The obvious methods are to require a length count before each argument or a delimiter byte between each argument. I have already contended (following the ARPA FTP model) that ANY character is legitimate in the filename syntax of a given filesystem. It seems most reasonable to reserve carriage return (CR) as a delimiter for file pathnames. (I could be convinced that it should be CRLF, though.) Thus, the RENAME-FILE command would take two arguments, the old and new filenames, seperated by a CR. Likewise, the directory listing returned on the data stream by the FETCH-DIRECTORY command would contain filenames seperated by CR's (or CRLF's?). It seems reasonable to use the same method for the LOGIN command, which would (I assume) have three arguments, the username, the password, and the account (any of which can be empty) seperated by CR's. 2. Harry Chesley and I have discussed the need for a CHANGE-WORKING- DIRECTORY command (with one pathname argument) similar to the ARPA FTP XCWD command. In the CP/M environment this might have the effect of selecting a new user area and/or default disk drive. In the Unix environment it would be equivalent to a 'cd' command. 3. As I said in a previous message, the set of request codes is extensible, allowing for future additions; furthermore, a given site or implementation is free to implement a subset of the codes and reject any others. We should, however, enumerate a minimum workable set of request codes required of every implementation. Most likely this would include FETCH-ASCII, STORE-ASCII, EXIT (QRU makes no sense to me), and HELP. These required codes should be the low-numbered ones to simplify implementing a dispatch table. 4. Regarding the file transfer commands (FETCH/STORE-ASCII/BINARY), we need to work out a method for acknowledging the final success of the transfer, as opposed to the correct receipt of any given packet. This final acknowledgement would indicate successful transfer and storage of each packet as well as the successful final closing of the file. Harry has suggested an additional request code, PLEASE-DO ACKNOWLEDGE- COMPLETION, that the using-end would send to the serving-end on the command stream after sending the End-of-Data on the data stream. A reply of I-WILL ACKNOWLEDGE-COMPLETION would then mean that the recipient has successfully closed the file. This would apply only when storing a file, not when retrieving it. Furthermore, if the recipient of the file encounters an unrecoverable error (e.g. disk full, write error, operator needs to use the home telephone), there should be a method for initiating an abort at that point, rather than dumping the remaining packets in the bit bucket. Thus we need to add a method for initiating a transfer abort from either end. Dave Fylstra P.S. I respectfully request that REM please NOT quote the above paragraphs in his reply to this message.  Date: 14 November 1982 20:38-EST From: Robert Elton Maas Subject: Direct NON-SERPRO.TTY mail also To: PCNET-PROTOCOL at MIT-MC Oh yes, one other thing I forgot to put in FTP1 is direct (non-forwarded non-headered) electronic mail. The most common uses for this would be: (1) Checking for the existance of a mailbox before blindly sending mail; (2) Fetching one's own mail rather than waiting for the remote node to call you with it (useful if the host has no dialout hardware or for financial or policy reasons is unwilling to call your home); (3) Snarfing somebody else's mail that needs forwarding if you are a forwarding node and the host you're calling can't dial out. Feel free to submit proposals for this protocol, as I might not get around to thinking about it myself for a few days. It's not exactly a can of worms but can get a little hairy (please send me any mail you have addressed to any node within 2 degrees longitude and 1 degree latitude from 37.22N122.08W).  Date: 14 November 1982 20:14-EST From: Robert Elton Maas Subject: User Interface To: GZ at MIT-MC cc: PCNET-PROTOCOL at MIT-MC, DDEUTSCH at BBNC The current FTP1 protocol would support  AI:FOO BAR types of interactions, or in EMACS C-X C-R AI:FOO BAR. The RETRIEVE-FILE command in FTP1 protocol specifies only the remote file name, no the local fielname. The remote file server doesn't have any idea what the local user program will do with the data that arrives on logical stream 1, like store it in a file, print on console, or store in an EMACS/MINCE buffer. But your message did remind me of one major thing that's been suggested at various times but never specified (FFM promised a year to look into this but hasn't done one iota of work to date) -- transfering only part of a file instead of all of a file. Somebody should think about that aspect of the problem carefully and submit preliminary specs for a solution. For example, one might specify both a file name and a starting and ending byte number or word number or page number (physical TENEX/ITS pages, or logical ctrl-L delimited pages). Or search-strings might be sent and the server would actually perform a search and select the appropriate text between the two strings (or just return the byte numbers so the user program could check for reasonableness before actually starting the transfer). To me it looks like a big can of worms. I'd like somebody with a clear idea of how to make this NOT A CAN OF WORMS submit a nice clean idea. Sending part of a file requires no protocol at all. The user program merely locally finds the appropriate data in the local file and sends it as if it were a whole file. Sending some data (part or all of a local file doesn't matter) and having it patched into an existing remote file, replacing some data but leaving the rest in place, is even hairier. The data could be appended to the existing file with all the old data left in place, prepended to the file with all the old data shoved back, inserted in the middle with the later data shoved back, or used to replace something in the middle. If it replaces something in the middle of different size, later data may have to be shoved either forward or back. Add all this to the can of worms above! Somebody suggested Arpanet ought to have this kind of protocol many years ago but nobody ever designed anything. I think IFIP is going to look into this too. (I'll send Debbie Deutsch a copy of this message in case she has any comments about what's going on elsewhere. Perhaps somebody in IFIP or INWG or CCITT has actually solved this problem and we can learn from their solution.)  Date: 14 November 1982 19:40-EST From: Robert Elton Maas Subject: User Interface To: FJW at MIT-MC cc: PCNET-PROTOCOL at MIT-MC Date: 14 November 1982 16:50-EST From: Frank J. Wancho I prefer to design the user interface first, at least in some preliminary generic form, THEN design the underlying process-to-process interface. I take a slightly different approach. I think the right way to design the underlying protocol and the user interface is as totally independent tasks, linked at the start only by some preliminary idea of what functions are to be performed, and then linked at the end by some code to have the user interface call the underlying mechanism. The user interface should be designed initially as facade, a program that doesn't really do anything but just pretends to. This is tried on nieve users and experienced guinea pigs an improved until all users like it. Then is design is frozen and it is interfaced to the underlying mechanism. The advantage of this method is that the designers of the user interface don't have to wait until the underlying mechanism is done before they can actually test the user interface on various people, in fact the underlying mechanism doesn't even have to be started implementationwise at the time the user interface is finished (tested and documented). Furthermore, the people writing code for the user interface don't have to be constantly hassled with writing code to hook into the underlying mechanism and rewriting that code every time a major change is made in the user interface, being afraid to change the user interface for fear the code linking it to the underlying mechanism will have to be rewritten, and of course bugs in the underlying mechanism won't hamper work on the user interface. That's the approach I'm taking currently. The FTP1 specs are still in hot debate, but I'm going ahead writing a facade FTP user program to test out my idea of what the user interface should do. I'll then try it on myself and get it to where I like it, and only then write the code for actually performing FTP1 protocol and/or document my user interface. Unlike REM, I expect a user FTP interface to also ESTABLISH a connection by calling on already existing PCNET program or overlay to do that for me. Au contraire, you aren't unlike REM in this point. A stand-alone FTP-only user-program should certainly perform all the connection and disconnection stuff inside itself. It will of course call PCNET subroutines to do the actual work, instead of duplicating that code, but since the phone connection and FTP1-server-activation won't be established at the time the FTP-user-program is invoked (started) by the user, but will both be established during the time the user is typing various commands to the program (PUT (aka SEND or STORE or TRANSMIT), GET (aka FETCH or RETRIEVE or RECEIVE), DIRECTORY, RENAME, DELETE, ...), the phone and lower-levels connection (what we call HELLO) as well as the activation of the FTP1-protocol server (OPNSTR) must occur while the FTP-user-program is running, which in a subroutine-calling environment requires the FTP-user-program to acually perform connection (via calling PCNET library subroutines typically). Note that the FTP-user-program and the FTP1 protocol aren't the same at all. The FTP-user-program performs HELLO etc., then talks to the FTP1 server process using the FTP1 protocol, and finally performs BYE. Thus two "application programs" are involved (the user-FTP1-process which is part of FTP-user-program, and the server-FTP1-process which is on the other node), and two protocols are involved (the formal FTP1 protocol by which those two programs talk to each other, which must be the same on ALL pcnet nodes in order for any two nodes to exchange files, and the informal customized user-interface-protocol by which the user sitting at his/her workstation talks to the FTP-user-program, which can be different on every workstation and even can have multiple forms on a single workstation for the benefit of multiple workers or for other reasons, but which can also be the SAME when using different protocols such as MODEM2 or UCP or PCNET or Arpanet or CSNET in order that a worker can get used to FTP once and not get confused when switching networks, for example anyone is free to make their personal PCNET FTP program look EXACTLY like TENEX FTP except for the table of host names available). One other point must be made at this time. Having a stand-alone FTP-only program as described above isn't the ONLY way to invoke FTP1 protocol. It's also quite reasonable to invoke it from inside a TELNET user program. Thus right in the midst of running TELNET, virtually sitting 3000 miles away on some other machine, using your PCNET link as a reliable communication medium over noisy phone lines, getting useful work done 3000 miles away on that other machine, suddenly you want to download or upload a file. You shouldn't have to disconnect, terminate the TELNET program, run the stand-alone FTP-only program, and have it reconnect, then exit it and reconnect via TELNET to resume your virtual presence 3000 miles away. That's the way it currently is on the Arpanet, having separate FTP and TELNET programs that can't do each other's tasks, but that's not the way it has to be! In fact, this idea has already been tried, although with very poor programming standards and using an almost indecently crufty protocol, probably worse than MODEM2, at IMSSS at Stanford. There's a program to link SUMEX and IMSSS over a 1200-baud private line. While in that program, it's possible to press ctrl-Y to invoke linker command mode and while in command mode to invoke an FTP task, either send or receive a file. When the transfer is done or aborted, the program reverts to TELNET mode. I see no reason why this kind of program can't be written for PCNET as well as the FTP-only program described above. In fact, most of the code for handling the user interface can be the same. While inside FTP mode the TELNET+FTP program would look exactly like the FTP-only program, and upon issuing a QUIT command would revert to TELNET without disconnecting from the host, rather than disconnecting and reverting to the workstation EXEC. The only thing hairy about doing this in simple mode is that nested processes aren't suported, so the TELNET+FTP program would have to somehow detach the remote job from under the TELNET server, exit the TELNET server, and enter the FTP1 server at the start, and exit the FTP1 server, enter the TELNET server, and reattach the detached job, when the FTP task is done. In enhanced mode with allowance for nested invocation of servers and dynamic allocation of streams, the implementation would be much cleaner, not requiring dismissing the old process when a new one is temporarily invoked inside it. The opposite is also possible, although not in simplemode, in the middle of an FTP task interrupting it to run TELNET for a while, then picking up the FTP right where it left off. For example halfway thru transferring a file one might want to do a FINGER on the remote host to see if somebody is logged in, and if so then to link to that person for a minute, then after unlinking get back to the long FTP in progress. Maybe my view is upside down, but other than some of the automatic and semi-automatic processes of the protocol which handle unattended operation, there is nothing, except this first stab at a real-time human interface to any PCNET process. You're right, FTP1 is the very first PCNET application-program protocol that has been designed towards end-to-end online-interactive work. The only other application-program protocol we've designed to date, MAIL1, which includes file-transfer qua messages, is expressly designed for non-interactive use, dumping header&body at night according to a prearranged (between user and workstation) schedule. We haven't yet designed any TELNET protocol although it should be easy. (All the application program needs is a data stream in each direction, methods for killing output like the ABORT-OUTPUT/DATA-MARK protocol on Arpanet, and watching for end-of-stream bit to indicate it's time to exit the TELNET application program, right?) I envision that you will eventually have at least two real-time human interfaces: FTP and TELNET, and a third unattended MTP. Is this discussion really about a fourth: an unattended FTP? Are you talking about the user interface or the underlying protocol?? If you're talking about the underlying protocol, no, that's already included in the MAIL1 application using SERPRO TTY header format for both electronic mail and electronic file transfer as well as possibly extending that protocol for remote job entry and information retrieval. MAIL1 using SERPRO TTY can adequately handle all non-interactive data-transfer operations. Only a tiny portion of it has yet been implemented in my LISP program (basically the electronic mail part for plaintext non-encrypted non-compressed messages). That's a powerful protocol that will gradually be implemented until it serves many non-interactive data-transfer uses. If you are talking about the user interface and various "programs" available to the user (more likely subroutine calls from a toplevel workstation menu), yes, if any use is to be made of forwarded file transfer using MAIL1 + SERPRO TTY, somebody needs to write a user program to set up a queue of messages whose header says FILE: instead of MAIL: and whose body is a file rather then a letter/memo. If somebody wanted to send a file to MIT-MC that way, it'd actually be possible now. My PCNSR6 (LISP) program understands only MAIL: in headers, so the header would be rejected and the entire message would be stuck in REM's mailbox for manual handling. I'd see the MAIL: line and manually perform the task of extracting the body of the message and depositing it in a disk file with the specified name. If somebody started sending me a lot of such messages I'd add code to PCNSR6 to recognize the FILE: line and do the task fully automatically to reduce my workload. Now that the MAIL1 protocol is defined and implemented, I encourage anyone interested in this unattended-send-file mode of operation to go ahead and write the code on his/her micro and start sending such FILE: messages to my PCNSR6 program. then there is nothing wrong with specifying a minimum and optional set of user interface commands NOW, and get agreement on that before you wedge the underlying design into a corner that would make it difficult to undo to accomodate any particular command that should have been included in the first place. I don't think the underlying design will impact the user interface as drastically as you suggest. Since we have hooks for both unattended (MAIL1 + SERPRO TTY) and interactive (FTP1) operation, and both protocols can be used during a single PCNET connection merely by closing one "application program" (server process) and opening another, or by nesting or multiprocessing in advanced nodes, I think the protocol can support just about any file-transfer or electronic-mail scenerio you might envision or want with only addition of new upward-compatible features and no total redesign of the underlying protocol. But feel free to prove me wrong if I am mistaken. I believe that full blown advanced mode PCNET with full-duplex lower-level protocol, multiple active proceses and flow control of the various streams, with MAIL1 FTP1 and TELNET protocols extended in compatible ways, can do anything you would want along those lines (except of course for being limited by the bandwidth of your modem).  Date: 14 November 1982 16:50-EST From: Frank J. Wancho Subject: User Interface To: REM at MIT-MC cc: PCNET-PROTOCOL at MIT-MC I really am not as confused as it may appear at times. My problem is that I prefer to design the user interface first, at least in some preliminary generic form, THEN design the underlying process-to-process interface. Unlike REM, I expect a user FTP interface to also ESTABLISH a connection by calling on already existing PCNET program or overlay to do that for me. Maybe my view is upside down, but other than some of the automatic and semi-automatic processes of the protocol which handle unattended operation, there is nothing, except this first stab at a real-time human interface to any PCNET process. I envision that you will eventually have at least two real-time human interfaces: FTP and TELNET, and a third unattended MTP. Is this discussion really about a fourth: an unattended FTP? Sort of a batch process similar to the way PCNET mail is handled now? If so, just ignore me; if not, then there is nothing wrong with specifying a minimum and optional set of user interface commands NOW, and get agreement on that before you wedge the underlying design into a corner that would make it difficult to undo to accomodate any particular command that should have been included in the first place. --Frank  Date: 14 November 1982 07:20-EST From: Robert Elton Maas Subject: new version of FTP1 PRO ready for review To: PCNET-PROTOCOL at MIT-MC Ok, I've finally finished excerpting from the messages from Fylstra and Chesley the specific suggestions as to protocol features, appending these suggestions to the end of FTP1 PRO, and extracting out the commands and adding them to the table of commands. I haven't yet merged in the suggestions with the main text, that is all the new descriptive paragraphs are at the very end even though the opcodes and command names are now in the main table. PCNET;FTP1 PRO is now available for further review and debate. Next I may start writing documentation for suggested features for a user interface. I'll include some of the suggestions FJW sent me earlier (when I was asking for review of the FTP1 protocol), and then I'll announce that file for review, although as I said yesterday I don't think we need to define the user interface solidly, I think each programmer should be free to adapt the interface he/she writes to the hardware interface (CRT&KBD and maybe mouse) available.  Date: 14 November 1982 06:39-EST From: Robert Elton Maas Subject: FTP etc. commands with more than one argument To: PCNET-PROTOCOL at MIT-MC There are two major ways to perform an operation that requires two arguments. One way is to break it into two separate operations, one that gobbles the first argument and sets a global state variable, and another that gobbles the second argument and refers to the state variable for the other (first) argument. The second way is to pass both arguments in a single command, which requires some way to separate the two arguments. Regarding FTP1 protocol and similar protocols, LOGIN is such an operation. Typically one must specify both an account (username) and a password. The Arpanet seems to use the two-separate one-argument-each method. I prefer the one-command method, with the two arguments separated by some delimiter character. If we use the two-separate-commands method then we'll need two login commands (account and password), two rename commands (rename-from and rename-to), etc. I don't like this proliferation of halves of commands. I'd rather put each logical command in a single physical command, with as many arguments as it needs, separated by delimiters. The only major disadvantage of using delimiters is that the delimiter can't be used in the body of the arguments (quoting is ugly at this level of protocol, and who would want inside a filename anyway?). Actually since we use 7-bit ASCII for arguments but have 8 bits available at this level of protocol, maybe the delimiter could have the 8th bit set, and then all 128 ASCII characters could appear in arguments? (Worry, do any systems use all 8 bits in filenames, like have files named "FOO" "BAZ" and actually encourage people to type such names that can't even be listed on ASCII printers?) What do the rest of you think/feel/want?  Date: 13 November 1982 07:37-EST From: Robert Elton Maas Subject: Interactive FTP proposal To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC Date: 12 Nov 1982 at 1228-PST From: fylstra.tsca at SRI-Unix I would like to propose a more sophisticated alternative to Robert's FTP1 proposal. Yeah, I'd like you to also. I've been waiting a year for FFM to do it (he agreed to at our meeting 1981 October), and I've been waiting several months for you to do it. Now that I've timed out and spent the time myself to do it, there's no point in you wasting my effort by doing it yourself, might as well spend your time finishing the C version so it works on a modem using correct protocol, or at least so you're willing to release it for somebody else to work on. I think at least two people are currently waiting for you to let them work on it, and I'm waiting for a demo to verify if it works. -- Don't make the Greg Shaw PASCAL mistake of making it so complicated/elaborate that you never get it working, that after a year working on it it's no closer to release that it was when you started. Just Keep It Simple! What I have in mind is an interactive FTP modeled after ARPANet FTP. The service should provide ASCII and Binary FETCH and STORE commands; remote directory listing; wildcard file transfers; and (possibly) remote file renaming and deleting. The protocol should be extensible and should allow implementation of a subset of the full range of commands. Ok, I'll throw those into my specs. Suggested request codes: 0 = EXIT / I've already specified 1 as exit (qru). 1 = HELP / Any urgent reason it should be 0 instead of 1??? 2 = FETCH-ASCII 3 = STORE-ASCII 4 = FETCH-BINARY 5 = STORE-BINARY 6 = FETCH-DIRECTORY 7 = DELETE-FILE 8 = RENAME-FROM-FILE 9 = RENAME-TO-FILE Otherwise I'll add the ones you have that I don't have. The server FTP returns an 8-bit reply code I assume you mean a 2+6 I-Will or I-Won't code like we've been using everywhere else in PCNET. and an explanatory string of arbitrary length (up to the end of the packet) intended for printing on the console or recording in a journal file. The 8-bit reply code indicates the status of the request: File not available, delete permission required, store request accepted, unknown command (to be enumerated later) Hmmm, apparently you don't! Maybe you mean that after the I-Won't return there's another byte that gives more specific info (optional, simple nodes running in very cramped memory or with limited programmer time will just say I-won't with no explanation byte), and after that numeric specific info byte there's optional text. Fine by me. Note to all, we decided a long time ago that we want to make "I CAN'T DO THAT" reply codes to need absolutely minimal code. Our standard is if any positive message (Please-Do or I-Will) it doesn't understand comes thru the node may simply ignore it totally (really simple nodes) or toggle the two bits to convert Please-Do into I-Won't and I-Will into Please-Don't; while if any negative message (Please-Don't or I-Won't) it doesn't understand comes thru it must ignore it totally. Furthermore if any of these appears in a place where such messages aren't permitted at all (i.e. *any* node-control message sent to a simple node at *any* time an application program instead of the node-control process is in control, or any application-program control message coming at an inopportune time (such as in the middle of a file transfer on a node that can't abort file transfers), it is the option of the offended node to either hang up the phone immediately or totally ignore the message. In advanced nodes that permit unexpected node-control messages right in the middle of the time when some application program instead of node-control is in charge, the nodes should at the very least toggle the two bits for unacceptable requests and offers rather than just ignore or hang up the phone. -- I believe this should NOT be changed. If we want to introduce Arpanet-style replies, a number that says more than just "no", they should be in ADDITION to the I-Won't or Please-Don't reply rather than REPLACING it, and should be OPTIONAL in all cases.  Date: 13 November 1982 06:31-EST From: Robert Elton Maas Subject: Interactive FTP proposal To: FJW at MIT-MC cc: PCNET-PROTOCOL at MIT-MC Date: 12 November 1982 19:57-EST From: Frank J. Wancho Don't forget: CONNect sitename - which should search a HOSTABLE and auto-dial (or whatever) as indicated in that table and perform an "ICP" - such as sending a couple of CRs to autobaud and whatever else is necessary to fire up the remote FTP. You're confused. At the time the FTP1 protocol is used, you've already told your user interface what host you want to connect to, the number is already dialed, modem carrier is already established, PCNET login is already done, the end-of-hello turnaround has been sent from the host and acknowldged by the caller, probably NODE-ID control messages have already been exchanged, and OPNSTR control messages have been exchanged to open the FTP1 process. At this point, a CONNECT command wouldn't make sense at all. LOGin name or ANONYMOUS PASS password (may be on same line as LOG) These two are resonable for actual protocol between the two nodes. BYE gracefully disconnects from the remote host I already have QRU which is BYE from the FTP1 process, returning back to the node-control process in case the user wants to run the MAIL1 or the CHESS or the GO or the ISR etc. before disconnecting. Of course at the user interface there might be a BYE command that both quits the FTP1 process and also quits the telephone connection. This would be appropriate when there's a user FTP program that doesn't have hooks for MAIL1 or any other protocol. It would automaticlly do HELLO and NODE-ID and also start up the remote FTP1 server, all in response to a CONNECT user command, then at the end automatically undo all levels of connection upon a BYE user command. QUIT (which may leave the connection active subject to another local activation of the user FTP interface - implies that the program must be able to recognize at startup that a previously active connection was established, and what condition/state it was left in.) I don't understand this except in the context you're confused, talking about the user interface again. I haven't written anything for that yet, and it's not crucial that the protocol committee make any decisions, although any individual programmer must decide what command structure his/her program will use. But I see no need for a standard of the user interface or even what features ought to be implemented. That's all up to the programmer. ^G user abort of a tranfer in progress. This doesn't make sense at all. There's no way a ctrl-G over the modem will be a magic exit-from-file-transfer signal. If you want to abort the file transfer, you send a packet containing something the FTP1 process understands. Some FTP1 servers may not accept this, and may thus generate an error message and hang up the phone rather than gracefully abort the file transfer but stay in PCNET protocol. I really think you're confusing the user interface with the FTP1 protocol specs here. ---- Note, some of your suggestions above are worthwhile ideas for the user interface, as are those of Fylstra and/or Chesley. I'll probably write something summarizing the sort of features a FTP user interface ought to have but without getting too specific about the command structure. I'll probably document what I do in my LISP program and list all the good ideas I didn't implement as an appendix. On the Arpanet several different user FTP interfaces exist. I've used at least three totally different ones (SU-AI (10/50), MIT-MC et al (ITS), and IMSSS (TENEX)) and despite their differences they can all talk to each other because they all use the same FTP protocol and I can use all three easily because their user-interface differences really aren't hard to remember. May a thousand flowers bloom, including tty-oriented user interfaces like the three I mentionned already, display-oriented user interfaces such as GNU's Apple faire demo, mouse&display-oriented user interfaces such as those on Dolphin and Alto workstations at Xerox, etc. etc.  Date: 13 November 1982 06:00-EST From: Robert Elton Maas Subject: Re: Interactive FTP proposal To: chesley.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC In simple mode we don't put in niceities such as handling of unexpected control messages, either node-control or application-process-control, however there's no reason not to put it in the formal protocol so that advanced nodes can make use of it and simple nodes can avoid ever sending it but on receipt generate a fatal error message and hang up. [MIT-MC CRASHED AND I LOST ABOUT 10-20 LINES OF MESSAGE. I HAD TO LEAVE TO CATCH THE BUS TO GO TO GO CLUB SO BY NO I'VE TOTALLY FORGOTTEN WHAT I TYPED ABOUT 8 HOURS AGO THAT WAS LOST]  Date: 12 November 1982 21:07-EST From: Robert Elton Maas Subject: Re: Interactive FTP proposal To: chesley.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC In simple mode we don't put in niceities such as handling of unexpected control messages, either node-control or application-process-control, however there's no reason not to put it in the formal protocol so that advanced nodes can make use of it and simple nodes can avoid ever sending it but on receipt generate a fatal error message and hang up. Printing a progress report such as percentage of file done or giving a countdown to its end is irrelevant to the protocol, providing that node(s) wishing to display such a progress report have available the file size at the start of the transfer. It would be silly not to notify the tended node of the file size and then have to periodically interrupt the flow of data on the 300 baud port to insert percentage-done messages. The tended node should count the bytes that pass thru it, and compare this count with pre-computed percentages of the total file size (or divide in real time) to generate the display. I will be preparing a separate document, or another part of that document, which describes the user interface in the program I implement hee on MIT-MC which may or may not be used as a guideline for other implementations. I'll probably put in a countdown (tenths of file remaining printed as numbers, plus a "." every 8 packets) in my LISP program.  Date: 12 November 1982 20:50-EST From: Robert Elton Maas Subject: Interactive FTP proposal To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC I dislike with your suggestion that binary be defined as a stream of 8-bit bytes with no defined relationship between the bits in these bytes and the bits in the machine words at each end of the link. First, it doesn't permit 36-bit or other non-multiple-of-8-bit transfer unless there are such a number of words that the file is an exact multiple of 8 bits; i.e. if you have a file of five 36-bit words there's no way you can map that to any number of 8-bit bytes. If you round up, you'll get a 6th word at the other end. If you round down, you may lose a word of zeroes at the end of the file, which may be crucial for correct function of the file as data to some program. Nay, I say we should treat binary files as a stream of bits, although of course for 8-bit systems this is functinally equivalent to a stream of bytes, but it allows PCNET protocol to work on 36-bit machines. Second we shouldn't leave the mapping between bits and words undefined, because then people will implement in confilicting ways and a transfer between two 36-bit machines using software written by two different people may result in scrambling the bits all over the place instead of the expected transparent 36-bit data transfer. By defining the correct mapping between the bits in a random-length word and the bits in the 8-bit bytes we're actually transferring, we assure that two implementations on machines with the same word size, both conforming to our specs, can successfully transfer a file without scrambling the bits, and furthermore that files can be temporarily stored on a wrong-word-size machine and later forwarded to a machine with he correct word size and the file will surely end up with all the bits in the right place.  Date: 12 November 1982 20:35-EST From: Robert Elton Maas Subject: Interactive FTP proposal To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC When you say "logical stream 0" and "... 1" you are merely using a different numbering scheme from what I'm using. My 1 is your 0 and my 2 is your 1 because you are using zero origin (as I do most always) while I'm using one origin (because of special circumstances; I don't want nieve users confusing physical stream 0 which is addressed to the node-control process with the first logical stream which is addressed to the application program, so I have the first logical stream called 1 instead of 0). What we call it, 0&1 or 1&2, is of course irrelevant except in documentation and communication. At this time the more important thing is exactly what bytes will be sent on the FTP-control and FTP-data channels rather than whether our documentation use zero- or one- origin, so I hope we don't get into a debate over origin.  Date: 12 November 1982 19:57-EST From: Frank J. Wancho Subject: Interactive FTP proposal To: fylstra.tsca at SRI-UNIX cc: FJW at MIT-MC, PCNET-PROTOCOL at MIT-MC Don't forget: CONNect sitename - which should search a HOSTABLE and auto-dial (or whatever) as indicated in that table and perform an "ICP" - such as sending a couple of CRs to autobaud and whatever else is necessary to fire up the remote FTP. LOGin name or ANONYMOUS PASS password (may be on same line as LOG) BYE gracefully disconnects from the remote host QUIT (which may leave the connection active subject to another local activation of the user FTP interface - implies that the program must be able to recognize at startup that a previously active connection was established, and what condition/state it was left in.) ^G user abort of a tranfer in progress. --Frank  Date: 12 Nov 1982 at 1358-PST To: fylstra.tsca at SRI-Unix Cc: PCNET-PROTOCOL at Mit-Mc Subject: Re: Interactive FTP proposal In-reply-to: Your message of 12 Nov 1982 at 1228-PST. From: chesley.tsca at SRI-Unix Via: Sri-Tsca; 12 Nov 82 13:58-PST I would add two commands: GET-LONG-DIRECTORY -- Returns a long version of the directory, including file sizes, types, whatever the other system thinks might be interesting; this is intended strictly for human consumption, and can thus be of arbitrary format; one file per line is recommended, tho. GET-FILE-SIZE -- Returns an ASCII string telling the size of the file in K bytes. This can be used by the program for information purposes. On small systems, especially with tiny floppies or cassette tape, it's imperative to know how big files are before you transfer them. Also, I've always wished Modem 2 would print out a percent done message as it goes along; GET-FILE-SIZE would let it do this. Also, you need a more definite description of tabs. If 8 is just the default, how do you change it. I think we just want to say it's 8, and not worry about being able to change it. Another random question: Is it possible to gracefully abort a transfer? This applies to all of PCNet, not just FTP. It may be in the documents somewhere, and I've just forgotten. --Harry...  Date: 12 Nov 1982 at 1228-PST To: PCNET-PROTOCOL at Mit-Mc cc: fylstra.tsca at SRI-Unix Subject: Interactive FTP proposal From: fylstra.tsca at SRI-Unix Via: Sri-Tsca; 12 Nov 82 12:33-PST I would like to propose a more sophisticated alternative to Robert's FTP1 proposal. I don't have time to go into detail right now, but hopefully will flesh this out in a few days. One of the major areas where the PCNet protocols win over things like MODEM2 is in the area of reliable (logically) full-duplex process- to-process communication. FTP is an application where we can capitalize on this facility to provide truly impressive functionality. Once they see what we can do, they'll never go back to MODEM2 again. What I have in mind is an interactive FTP modeled after ARPANet FTP. The service should provide ASCII and Binary FETCH and STORE commands; remote directory listing; wildcard file transfers; and (possibly) remote file renaming and deleting. The protocol should be extensible and should allow implementation of a subset of the full range of commands. Logical stream 0 will be a command/reply channel for communication between two protocol interpeters which are simple finite state machines. Logical stream 1 will be a data transfer channel. Suggested request codes: 0 = EXIT 1 = HELP 2 = FETCH-ASCII 3 = STORE-ASCII 4 = FETCH-BINARY 5 = STORE-BINARY 6 = FETCH-DIRECTORY 7 = DELETE-FILE 8 = RENAME-FROM-FILE 9 = RENAME-TO-FILE The server FTP returns an 8-bit reply code and an explanatory string of arbitrary length (up to the end of the packet) intended for printing on the console or recording in a journal file. The 8-bit reply code indicates the status of the request: File not available, delete permission required, store request accepted, unknown command (to be enumerated later). The reply code is intended for consumption by the user protocol interpreter program; the explanatory string is provided strictly as a convenience to the human user and is optional. The HELP command returns a series of printable ASCII lines on the data stream that is intended for human consumption; it may indicate which commands are implemented, site downtime schedule, etc. The FETCH-DIRECTORY command returns a series of filenames seperated by CRLF's on the data stream. All other characters are possibly legitimate characters in a given filesystem's file specification syntax; only CRLF is reserved to delimit filenames. The user FTP is free to print the list on the console or record it on a file according to the whims of the operator. Wildcard transfers can be implemented by sending a FETCH-DIRECTORY command with the wildcard pathname to the server FTP and storing the resulting list of files on a local temporary file. This file is then read one pathname at a time and the corresponding FETCH or STORE command is sent to the server. Note that the wildcard string (like all pathnames) must be interpreted by the server in the context of the server's filesystem. ASCII is defined as a stream of 7-bit ASCII characters stored in an 8-bit byte with the sign bit zeroed. Lines are delimited with the two-byte CRLF sequence. No special character is needed to denote the end of file, which is signaled by the Directing Layer End-of-Data signal. Horizontal Tabs are acceptable and default to every 8 columns. The implementation is responsible for translating this format into the local system's customary format for storing text. Binary is defined as a stream of 8-bit data bytes of arbitrary length. It is up to the file creater and file user to agree on the internal format of the file; the storage format (byte packing into words, etc) is left to the implementation. Examples include CP/M .COM files, digitized speech, encrypted data bases, etc. All of this would be quite simple to implement in the CP/M environment, and I think it provides a pretty significant enhancement in functionality over MODEM2. A given site is free to implement a subset of the commands and send refusal reply codes to any other requests. Dave Fylstra  Date: 11 November 1982 12:10-EST From: Frank J. Wancho Subject: Proposed FTP1 protocol, from the file REM;FTP1 PRO To: REM at MIT-MC cc: FJW at MIT-MC, PCNET-PROTOCOL at MIT-MC "Obviously" a typo: OPNUM 5 is STORE-BINARY, accept a binary file from requestor and write on disk, rather than STORE-ASCII... Note: I used "binary file" rather than "binary text file". --Frank  Date: 11 November 1982 04:04-EST From: Robert Elton Maas Subject: Proposed FTP1 protocol, from the file REM;FTP1 PRO To: PCNET-PROTOCOL at MIT-MC Preliminary proposal for PCNET File-Transfer-Protocol by Robert Elton Maas, 1982.Nov.11, very first draft This proposal is for transferring files under interactive control at the originate node. (It doesn't handle the other kind of file transfer whereby pseudo-electronic-mail is used as an envelope for files that are to be sent and possibly forwarded. See PCNET;SERPRO TTY for the latter, which is included in the function of the MAIL1 program although it hasn't yet been implemented anywhere.) This mode assumes the place where the file exists and the place where the file is wanted are directly connected by a PCNET link so that end-to-end negotiations can occur and so that fetching files FROM the answer node TO the originate node can occur within a single PCNET connection rather than requiring callback. (Files FROM the originate node TO the answer node can occur within a single connection in both protocols, so in that case this protocol has no special advantage over MAIL1 & SERPRO TTY.) The name of the "application program" (server) handling this protocol is FTP1. It is invoked in the usual way by one node (the originate node in simple mode) sending a Please-Do-OpenStreams node-control message with a query number and the characters "F" "T" "P" "1" as data (arguments) and getting back an I-Will-OpenStreams node-control message with the same query number, the starting stream number (always hexadecimal 81 in simple mode), and the number of streams (3 in this case). Logical stream 1 (actual 81) is used to send service requests. Logical stream 2 (actual 82) is used to send the data of file. Logical stream 3 (actual 83) is used to send end-of-file acknowledgement in the opposite direction from the file, to verify the file is now safely on a non-volatile [NB AT THIS POINT IN TYPING THIS FILE THE WORD OF BRESHNEV'S DEATH ARRIVED FROM GUMBY, CONFIRMED BY KCBS RADIO] medium such as disk. On logical stream 1 the following 6-bit opcodes are used, modified by the two high-order bits that select I-Will etc. OPNUM Function 1 QRU, exit program back to node-control 2 FETCH-ASCII, fetch a text file from the server's disk to the requester 3 STORE-ASCII, accept a text file from requester and write on disk 4 FETCH-BINARY, fetch a binary text file and send to requester 5 STORE-ASCII, accept a text file from requester and write on disk ASCII transfers pass all 8 bits if available, but only 7 bits are guaranteed if the recipient happens to use 7-bit ASCII file storage. If the sending node uses EBCDIC or other non-ASCII representation, it must be converted to ASCII before sending. If the receiving node doesn't use ASCII, it must convert the ASCII data it receives into whatever it does use. Thus if both nodes are EBCDIC the data is converted to and from ASCII so that not all characters will pass thru correctly, however since one or the other node will probably be a microcomputer, and all microcomputers use ASCII, this won't be a problem. BINARY transfers consider the data to be a bit stream where each byte is decomposed with the high-order (most significant) bit considered to be first and the low-order (least significant) bit last. If both machines use 8-bit bytes, no repacking occurs. If both machines have something other than 8-bit bytes, but they are the same, data is repacked at both ends but ends up on the recipient's disk exactly as it left the sender's disk. If the two machines don't have the same word size, this protocol assures that no bits will be lost, although programs to use the binary data in the file will have to be written appropriately for our repacking standard. An example of a binary file thatmight be successfully transferred is a compressed file providing that the compressing and decompressing algorithms treat the data as a stream of bits in the same order we do and within that stream concept have identical algorithms on the two machines. The last block of the data, or an empty block after the end of the data, has the last-block-bit set to indicate the end of the data. At that point, the receiving node saves the file to disk and then sends the final ack on logical stream 3, which consists of ASCII text "GOOD:" or "BAD:" followed by an optional explanation.  Date: 11 November 1982 02:46-EST From: Robert Elton Maas Subject: O8TOP works great! To: PCNET-PROTOCOL at MIT-MC O8TOP is the name of my toplevel test program for originate mode. It warns that it connects first then asks the operator what to do, thus can't be run unattended. Then it connects. Then it asks if you want to test the remote ECHO program. I said yes, so it used my standard test file for echoback test thru the ECHO program. Then it asks if you want to send the test-data file qua electronic mail. I said yes, so it sent it to the MAIL1 server, which noticed it didn't have a proper header so it forwarded it to REM for manual handling. Then it asks if you want to send some other files qua electronic mail. I said yes. It asked me for file names and verfied the files really existed. I gave it a good file, a bad one it rejected, and another good one. Then it started the MAIL1 server again and sent it these two files before returning back to the node-control process. Then it disconnected. Worked perfectly the first time! Now to get rolling on FTP...  Date: 11 November 1982 01:52-EST From: Robert Elton Maas Subject: PCNSR6 up to grade now To: PCNET-PROTOCOL at MIT-MC Well, it worked the first time, except the empty packets coming back (because electronic mail is uni-directional once preliminary negotiations ar done) confused me and I aborted it to investigate. It worked the second time too. -- Thus originate-mode electronic mail now works in PCNSR6 as well as answer-mode MAIL1 server program. I'm now going to clean up the toplevel user interface for the benefit of somebody who might be testing this on a micro, then I'm gonna make a stab at FTP. -- Various people including FFM and Fylstra have promised to write a document proposing what the FTP protocol should be, as far as I know it hasn't been written yet, so I'm going to invent my own ad hoc protocol to get me by until the formal protocol has been decided upon. I'll try as much as possible to do what Fylstra said he's using. [Fylstra, if you've written anything describing exactly what your proposed FTP protocol for ASCII and BINARY files is, please send it to me asap! Otherwise I'll have to guess from various messages you've sent to date.] As of the present moment, I'm leaning toward making negotiated FTP a different server from blind-forwardable MAIL&FTP (MAIL1). I'll probably call it FTP1. In a few minutes, as I actually start to write code, my decision will be more firm.  Date: 10 November 1982 05:35-EST From: Robert Elton Maas Subject: More addenda on PCNSR6 To: PCNET-PROTOCOL at MIT-MC PCNSR6 in originate mode now not only can conduct echoback test at levels 2, 4, and 6 of protocol, but can at the server level ask for the ECHO application program and conduct a full test at that level, picking a random stream for each block of data, veryfying all the PCNET protocol and the ECHO application program and the node-control process are all workin correctly. Next to implement electronic mail in originate mode, i.e. sending electronic mail from MIT-MC to MIT-MC by running PCNET protocol thru a pseudoteletype pipe...  Date: 9 November 1982 11:34-EST From: Robert Elton Maas Subject: addenda To: PCNET-PROTOCOL at MIT-MC Well, level 2 (packet framing) and level 4 (R41 conversion) echo test done and working. Level 6 (validation&sequencing) another day.  Date: 9 November 1982 09:10-EST From: Robert Elton Maas Subject: PCNSR6 progress To: PCNET-PROTOCOL at MIT-MC I've finished writing&debugging code for PCNSR6 to work as an originate node for purpose of the HDX protocol level echoback test. It functions essentially the same as my 8080 program, connecting to the remote host (in this case another MIT-MC job via a pseudoteletype), starting up the server on that host, selecting half-duplex echoback mode, then sending it packets of data and verifying they echo back correctly, aborting the test at the first error, then when done or aborted it logs off the remote job and disconnects. Next I plan to add the echoback tests at successively higher levels of protocol. When this is done, and originate-mode electronic mail is installed, the code will be ready to port to a micro with LISP and adapt to the I/O situation on that machine, without having to add any PCNET-specific code because it's all been done here already.  Date: 25 October 1982 06:40-EDT From: Robert Elton Maas Subject: Update on my PCNET programming To: PCNET-PROTOCOL at MIT-MC I've written code to get a pseudoteletype and log in as PCNET and start up the PCNET server and tell it to use all six upgrades for Radix-41 mode; and code to log out and release the pseudoteletype. This will allow PCNSR6 originate mode to connect to PCNSR6 answer mode and exchange protocol, with both incarnations of the protocol sitting on MIT-MC, thus I can now write LISP code for originate mode and get it debugged and run tests to verify the code is working before I install it on some micro with LISP. -- Next I have to modify the I/O to handle multiple I/O channels, like my 8080 code already does, then write the toplevel for conducting an echoback test or file transfer from originate node, then debug all this...  Date: 23 October 1982 17:36-EDT From: Robert Elton Maas Subject: Someone here may wish to comment on PCNET'S solutions to these issues To: PCNET-PROTOCOL at MIT-MC Date: 19 Oct 1982 1442-EDT To: HUMAN-NETS From: Greg Skinner Subject: Worldnet response It's a nice idea to dream about. However, the legal hassles alone (forget the implementation) would probably prevent such a thing from being developed in the next ten years or so. What with issues such as security, protection, etc., a totally distributed network consisting of local users running PCs would be extremely difficult to make safe, usable, etc. for all users without there being some centralized agency who is in charge of policy. For example, how would users be named in such a network. By name (given names)? Too many conflicts. By address? The addresses would most likely be akin to telephone numbers. (Hmm... could be a prelude to Visi-phones) Then, you want users to be able to add themselves to the Worldnet databases without intervention. A good idea in theory, but in case the users make errors in their applications the network must be smart enough to resolve those mistakes, lest great mixups occur when users try contacting and sending messages to each other. There should also be some sort of terminal compatibility requirement (most nets recognize a large variation of terminals, but yet in still a finite number not equal to ALL terminals in existence). Even still, you will always have the destructive hackers who will try to destroy the net from wherever they are transmitting. The net must (!!) be protected from destruction as much as possible, or it will be almost impossible to keep it up for long periods at a time. Still, it's a fun idea to think about. Maybe it should be tried on a smaller scale first (a distributed network of students with PCs at a university, perhaps a small city or large community). Who knows, with a PC in almost every home in a few years, maybe it'll be possible and desirable. --gregbo  Date: 20 Oct 82 20:21:59-EDT (Wed) From: Rick Conn To: fylstra.tsca at Sri-Unix cc: rconn at BRL, fylstra.tsca at Sri-Unix, PCNET-PROTOCOL at Mit-Mc, W8SDZ at Mit-Mc, RGF at Mit-Mc, RJM at Mit-Mc, CONN at Mit-Mc, fjw at Mit-Mc, leor at Mit-Mc Subject: Re: your message of 20 Oct 82 0:05:27-EDT (Wed) Hi, Dave, I like your ideas for a new form for the BDSCIO.H file regarding Modem access. The MACRO facility seems like a very nice answer to the problem. Re the difference between memory mapped and I/O mapped device access routines, what do you think about including a DE- FINE for the type of access you have and then #IFDEF ... #ENDIF blocks around the appropriate routines, rather than commenting sections out. Seems like this may be a cleaner design to me. What I'm trying to say is to use a form in BDSCIO.H like: #IFDEF IOMAPPED ... #ENDIF #IFDEF MEMMAPPED ... #ENDIF Also, I wrestled with the problem of a "universal" set of routines to give very general purpose support to communications under CP/M when I designed TERM II (the communications package I use and market). I tried to answer the question of how to sup- port all of the "nicer" communications facilities on the widest variety of systems I could envision, and I came up with the idea of having a BIOS-like Support Package which contained (1) a JMP table which gave position-independent access to the embedded rou- tines and (2) a set of routines for various features I would like to see available. If you bear with me, the following is the design I came up with. The Support Package is divided into 9 logical sections. The first section, which is implemented with all support pack- ages, contains the following set of routines: . a status routine which returns a code saying which of the following sets of functions are available . a routine which returns the end address of the Support Package in order to provide a pointer to a G-P buffer area . an error entry routine which returns an error code to the calling subroutine; this is branched to by the JMPs in the Support Package JMP table which are not implemented so that if they are called accidentally, no harm results . a character output routine (for messages) . a routine which returns the version number of the Support Package The Support Package is then structured as follows: 5 JMPs for the Standard Routines (described above) 5 JMPs for CRT Screen-Oriented Routines - Init - Foreground - Background - Clear Screen - GOTO XY 5 JMPs for Printer Routines - Init - Input Status (RDA) - Output Status (TBE) - Input Char - Output Char 6 JMPs for Modem 1 Routines - Init - Input Status (RDA) - Output Status (TBE) - Input Char - Output Char - Transmit Break 6 JMPs for Modem 2 Routines (up to 2 modems are supported) - same set of routines as for Modem 1 5 JMPs for Alternate Device 1 Routines - same set of routines as for Printer 5 JMPs for Alternate Device 2 Routines - same set of routines as for Printer 5 JMPs for Alternate Device 3 Routines - same set of routines as for Printer 15 JMPs for Telephone System Interface Routines - Init - Set Originate - Set Answer - Pick Up Phone - Hang Up Phone - Wait up to 15 secs for dial tone - Wait up to 15 secs for answer - Ring Detect - Dial Tone Detect - Carrier Detect - Start Dialing Sequence - Stop Dialing Sequence - Dial a Digit - 0.1 sec delay routine - Prepare to Answer Telephone One thing that I will probably add to the Printer, both Modems, and the three alternate device routine sets is a Carrier Detect function for each. This is a very flexible type of design. TERM II reads the status via the Support Package status routine and knows what devices are available, and it then configures itself for the par- ticular device set. It must have one modem minimum, but if CRT routines are available, it makes use of them. If Telephone Sys- tem Interface routines are available, it makes use of them also. And so on. I am really pleased with this type of idea, and would like to recommend that the BDSCIO.H file include this type of feature as well. Also, not all routines in each routine set must be active to declare the routine set valid. For instance, if a break transmit feature is not available for the modem, the transmit break routine returns a code saying it can't do it (function not available). Likewise, in the future addition of carrier detect functions, if a specific carrier detect capability is not avail- able, the routine will simply return a value saying that it detected a carrier. If the printer cannot transmit chars, the Input Status (RDA) routine from the printer simply returns a char not available code. I think this is a good kind of very general-purpose idea. Comments? Rick  Date: 20 Oct 1982 at 1352-PDT To: rconn at Brl Cc: fylstra.tsca at SRI-Unix, PCNET-PROTOCOL at Mit-Mc, W8SDZ at Mit-Mc, RGF at Mit-Mc, RJM at Mit-Mc, CONN at Mit-Mc, fjw at Mit-Mc, leor at Mit-Mc Subject: Re: your message of 20 Oct 82 0:05:27-EDT (Wed) From: fylstra.tsca at SRI-Unix Via: Sri-Tsca; 20 Oct 82 13:55-PDT (I hope I recreated this address list correctly...) Rick, I appreciate your comments on the PCnet I/O interface. Ironically, the method you mentioned (taking the Modem port definition from the BDSCIO.H file) is the method that I use now, and am specifically rejecting for exactly the reason you cite -- absence of support for memory-mapped serial ports. It has other weaknesses too: it doesn't support I/O-mapped ports that have TBE and RDA on different status ports or TxData and RxData on different data ports. These situations are admittedly rare, but they do occur -- e.g. the Novation Apple CAT has seperate addresses for Tx and Rx Data. Hence I am going to pitch the following solution to Leor. You all may wish to chime in with words of support! Leor, Now that BDS C has parameterized defines, I'd like to propose the following change to BDSCIO.H for the v1.50 package. It is intended to replace the existing modem port definitions with a more universal scheme. /* Comment the following out if your modem port is memory-mapped. This version is for the Potomac Micro-Magic Inc MM-103. */ #define MDM_TBE (inp(0xC0)&1) #define MDM_RDA (inp(0xC0)&2) #define MDM_TDATA(byte) (out(0xC1,byte)) #define MDM_RDATA (inp(0xC1)) /* Uncomment the following if your modem port is memory-mapped. This version is for the Novation Apple CAT. #define MDM_TBE (peek(0xE08F)&0x20) #define MDM_RDA (peek(0xE08F)&0x10) #define MDM_TDATA(byte) (poke(0xE08E,byte)) #define MDM_RDATA (peek(0xE08B)) */ These macros are intended to be used as follows: if (MDM_TBE) /* If modem transmit buffer empty... */ MDM_TDATA(byte); /* ...transmit the byte. */ if (MDM_RDA) /* If modem receive data available... */ byte = MDM_RDATA; /* ...receive the byte. */ I believe the above solution should make it possible to write completely portable Modem I/O code. It permits (a) the use of either memory-mapped or I/O-mapped ports; (b) RxData and TxData on seperate ports; (c) TBE and RDA on seperate ports; (d) TBE and RDA of high or low polarity. Dave Fylstra  Date: 20 October 1982 00:42-EDT From: Frank J. Wancho Subject: RFC: I/O interface To: fylstra.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC Date: 20 Oct 82 0:05:27-EDT (Wed) From: Rick Conn To: Frank J Wancho cc: W8SDZ, RGF, RJM, CONN Re: [fylstra.tsca: RFC: I/O interface] I like Dave's idea of combining (2) and (3), since (2) alone typically does not take memory-mapped I/O into consideration while (3) does if necessary. Having (2) also available leaves easy configuration for those with more conventional I/O. One thing he omitted, however, which should be added to the (2) and (3) combination (in my opinion) is a third addition to this combination which extracts the necessary information from the BDSCIO.H file. This header file, which *should* be properly configured by each BDS C owner, already contains Modem equates, for use by TELNET specifically, and all the information is already there and need not be duplicated elsewhere. Rick  Date: 19 October 1982 23:08-EDT From: Frank J. Wancho Subject: RFC: I/O interface To: fylstra.tsca at SRI-UNIX cc: FJW at MIT-MC, PCNET-PROTOCOL at MIT-MC As screen after screen went by, I was dying to mention the jump table idea, and then, you finally got around to saying it! Although there is plenty of merit in the lazy man's INSTALL-type program, ala W*, the initial interest and distribution will probably interest mainly the hackers amongst us who sit on the fringes of the PCNet world, patiently waiting for someone else to do an implementation. I have, over time, done all three options you suggest with MTN. The one in current public release has an "install" mode that you get when you first run it. After going through all the options, it modifies itself and saves itself to disk, less the install code. The new experimental versions we have been beta testing for the last year has both a skeleton PATCHMTN.ASM file and an MINSTALL program. The user is free to use either to produce a patch overlay which can either be permanently overlaid into the main program, or optionally named on the command line. The latter option frees the disk space from multiple copies of various full versions... With the MINSTALL as a separate program, you can cover maybe 90% or more of the major configurations and the user would never need anything else. You cover the other 10% by giving them the skeleton patch file. I have forwarded your message to a couple of other interested parties, W8SDZ, RGF, RJM, and CONN, (Keith Petersen, Ron Fowler, Bob Mathias, and Rick Conn). I suspect you should be hearing from one or more of them soon. --Frank  Date: 19 Oct 1982 at 1759-PDT To: pcnet-protocol at Mit-Mc Cc: fylstra.tsca at SRI-Unix Subject: RFC: I/O interface From: fylstra.tsca at SRI-Unix Via: Sri-Tsca; 19 Oct 82 18:03-PDT As many of you know, I am working on PCNet implementations for V7 Unix (in C) and CP/M (in BDS C). Successful file tranfers between Unix and CP/M systems have already taken place, and I am currently upgrading the protocol to the current version. Please don't inundate me with requests for copies yet...there are a few unfinished areas that need to be cleaned up before it is ready for initial release. The purpose of this netnote is to solicit suggestions on how to handle the interface to the site's hardware and customizable options in the CP/M version. Here are a few issues I believe are important: (1) The I/O should be provided in a seperate module with a well-defined interface. For one thing, I don't want to tempt people to modify the modules that actually implement the protocol until they really understand how the protocol works. (2) Naturally it should support the usual modem functions such as data I/O, dialing, hook control, orig/ans selection, and possibly options such as dialtone detection. I would also like to support a simple display-oriented console interface (gotoXY, putchar, clrscreen), and possibly a realtime clock if one exists. (3) Not everyone has the BDS C compiler. This was an issue with things like MODEM2, for instance, which was partly so successful because everyone had (and could afford) ASM. (4) MODEM2 already works pretty well, and most people trust it and are very familiar with it. The PCNet implementation should be EXTREMELY easy to install, at least in a bare-bones version, so that anyone can give it a try without too much pain. Given the above, here are a couple of approaches that we've been kicking around: (1) Provide one standard version written entirely in BDS C with a variety of manifest constants to control things like I/O port assignments, etc. This requires the site to have the BDS compiler and linker and to be willing to perform the edit and compile. (2) Have a self-contained initialization dialogue that might be invoked by, e.g. "pcnet -i". The user would then need to download only the PCNET.COM file using MODEM2, execute it, and answer the configuration questions. It probably would ask the node ID number and define the modem port hardware, patch itself accordingly, and request the user to type "SAVE 70 PCNET.COM". The PCNet program itself could then be used to transfer the remaining files in the package en masse. The advantage of this approach is that it is extremely simple to perform just to give PCNet a try. As for disadvantages, aside from the space needed in the .COM file for the configuration code, it is very difficult to write one piece of code that can handle virtually any type of modem in any really fancy way. Compare this with a universal gotoXY routine. (3) Have a module written in assembly language (using ASM) at a standard location and length that provides jump-table access to all of the modem, display, and clock routines, somewhat like CP/M's BIOS. The user could then write his own drivers to interface to his hardware, assemble it, use DDT to overlay the .HEX file on top of the I/O area in the .COM file, and SAVE it. This eliminates the need for a C compiler, and permits some pretty fancy customization. The disadvantage is that the I/O area has to be in a standard place that might inhibit the expansion of the rest of the .COM file. Perhaps the ideal solution is to combine approaches (2) and (3). The second approach is good for bootstrapping and giving the user some incentive to try it out; then once you have used the bare-bones copy to download the entire package, you can use the third approach to customize it to your heart's content. The first approach allows the owner of the BDS C compiler to add new application programs on top of the Directing layer and to modify the protocol itself. Any suggestions? Dave Fylstra  Date: 19 October 1982 18:17-EDT From: Robert Elton Maas Subject: Proposed hook to support PCNET-style addressing for multiple protocols To: PCNET-PROTOCOL at MIT-MC Regarding source routing vs. other ideas such as PCNET, an anonymous person working with IFIP WG 6.5 and with NBS on electronic mail standards said: I agree with you. Source routing has definite disadvantages. Furthermore, doing something one way because the method "is already in wide-spread use..." can be reminiscent of lemmings casting themselves into the sea.  Date: 18 Oct 1982 at 0957-PDT To: Robert Elton Maas Cc: PCNET-PROTOCOL at Mit-Mc Subject: Re: Proposed minor protocol change to support Worldnet/Internet In-reply-to: Your message of 16 October 1982 05:22-EDT. From: chesley.tsca at SRI-Unix Via: Sri-Tsca; 18 Oct 82 9:57-PDT Unfortunately, the topology of USENET is more complicated than that. Many routing decisions are made, not on the basis of geographical distance, but rather on the basis of (1) cost distance (for example, some sites have incoming or outgoing WATS lines, which let messages get long distances for free), (2) local politics (e.g., UCB forwards a lot of mail between USENET and ARPANET because they're fairly open about such things, while other places a very paranoid about loading their machines, etc.), and (3) knowledge of the net topology (e.g., the net is now so large and complex that optimum paths may be missed simply because a given site doesn't know there's another site across the street). Also, because of (2), optimizing overall costs is not always the criteria for a good route, at least from the point of view of the site that has to pay. This is a very complex problem area. Source routing is one solution, one which works as well as the capabilities of the sender to figure out the best route. It's possible that some site or sites could offer a recommended routing service, by collecting together a network topology map and finding good routes. The PCnet scheme is another solution (and also a good one), but one which doesn't work as well when there are criteria other than geographical distance for determining a good route (there are ways to get around that problem too). I don't think there is a "best" solution to this problem; at least it hasn't been found yet. But source routing is already in wide-spread use, and I, for one, would like to be able to send mail from PCnet to my friends on USENET and to read HUMAN-NETS from the ARPANET. --Harry...  Mail-from: SU-NET host Shasta rcvd at 16-Oct-82 1414-PDT Date: Saturday, 16 Oct 1982 14:15-PDT To: Robert Elton Maas Cc: chesley.tsca at SRI-UNIX, PCNET-PROTOCOL at MIT-MC Subject: Re: Proposed minor protocol change to support Worldnet/Internet In-reply-to: Your message of 16 October 1982 05:22-EDT. From: Brian Reid Agreed; uucp source routing is a disaster, and is not acceptable for a network with an order of magnitude more nodes.  Date: 16 October 1982 05:22-EDT From: Robert Elton Maas Subject: Re: Proposed minor protocol change to support Worldnet/Internet To: chesley.tsca at SRI-UNIX cc: PCNET-PROTOCOL at MIT-MC UUCP is my main target for this proposal because currently USENET is having horrible problems with routing. Every day or so another message in HUMAN-NETS or SPACE or WORKS shows up with a return address that isn't a complete route thus can't be used at all for return messages. It take a day or two (one time it took a couple weeks) to ask around and find some route for the return message. The larger USENET gets the worse this problem will become. If they had an absolute address such as PCNET has (something that includes the phone number), it'd be possible to send messages without magically discovering a route, any UUCP node could call any other direct and actually save money over the multi-hop calls that are presently used along established routes (I've seen some with 6 or 8 hops; if even two of those hops were long distance telephone instead of leased line, one direct end-to-end call would have been cheaper). Thus if we set up some way to make our addressing system work for USENET and PCNET compatibly, they might find adopting it is better than the present USENET disaster.  Date: 15 Oct 1982 at 1745-PDT To: Robert Elton Maas Cc: PCNET-PROTOCOL at Mit-Mc Subject: Re: Proposed minor protocol change to support Worldnet/Internet In-reply-to: Your message of 15 October 1982 19:02-EDT. From: chesley.tsca at SRI-Unix Via: Sri-Tsca; 15 Oct 82 17:43-PDT Actually, the current mail systems use NCP/TCP/UUCP, via source routing (i.e., "chesley@tsca@sri-unix@..."). This approach is sufficient for most applications, and is decentralized. A different approach is likely to meet with considerable resistance from the TCP/UUCP community. Or rather, they won't resist it; they just won't do it. PCnet is good at dial-up network packet/message transport. I could see it replacing or supplementing UUCP is this area. I would recommend using the same mail addressing scheme as other's use, rather than something different and incompatible. --Harry...  Date: 15 October 1982 19:02-EDT From: Robert Elton Maas Subject: Proposed minor protocol change to support Worldnet/Internet To: PCNET-PROTOCOL at MIT-MC At times various PCNET people have proposed that the node ID contain some information about initial parameters so that nodes can decide whether to dial directly or go through a forwarding node without having to first dial directly and only then discovering direct communication is impossible or undesirable. Recently several other protocols, besides PCNET, have been suggested by various people for use in establishing a worldwide network with more than a million nodes. TCP/IP is a major suggestion because it's being used for Arpa/Internet, while UUCP is also because a decentralized network already exists with that protocol. It may indeed be that WorldNet will come into being using a mixture of these three protocols plus perhaps others. Unfortunately there's no addressing scheme for electronic mail or for node identification in general that includes all these protocols in a compatible way. I propose modifying the PCNET node-ID system for this purpose. After the latitude longitude and telephone number, we would include another field that indicates the preferred protocol and any parameters needed for connection such as baud rate or modem type. Since there are only a limited number of protocols, and they start with different letters (P T and U), we can use a single letter to denote the protocol. Next can come the baud rate, or the character rate (one tenth of the baud rate); which would be best? Finally, or before the baud rate, can come the modem type in case where there is more than one choice, such as Vadic/Bell 1200 baud modems. The only already-written code that I know of that would be affected by this proposal is my LISP program at MIT-MC. Thus if this change were made now, only documentation and my program would have to be modified. What do you-all think of my idea?  Date: 11 October 1982 03:15-EDT From: Robert Elton Maas To: PCNET-PROTOCOL at MIT-MC My directory is full and I no longer can afford to keep PCNET OV1 around. I never did get any significant feedback since it was written in 1981, so I guess nobody had time to read it. I'm moving it to SU-AI where it'll reside until backed up on tape, then it'll exist only on tape. Last chance to read it now. It'll exist for a week or so as PCNET.OV1[1,REM]  Date: 5 October 1982 11:44-EDT From: Robert Elton Maas Subject: Examples of protocol To: PCNET-PROTOCOL at MIT-MC ECHO TRANS and MAIL1 TRANS, previously in separate files by those names, examples from the point of view of PREAD/PWRITE of using the application programs ECHO and MAIL1 respectively, have now been moved into the main file of recent test data, PCNET;EXAMPL WRU.  Date: 20 September 1982 03:15-EDT From: Robert Elton Maas Subject: test data with CRC To: PCNET-PROTOCOL at MIT-MC cc: TVR at SU-AI, Danielson at PARC-MAXC I've added 8-bit-transparent test data with SDLC CRC to my file of test data. See below for this new part. See PCNET;EXAMPL WRU for all the new test data to date. Please suggest new types of test data that would be useful for our document. 00 FF C0 DB DD 90 40 5B 5D 10 77 34 (SEQ=3 WANT=5) {validation} 00 FF C0 DB DD 90 40 5B 5D 10 77 34 1D A9 F2 {8-bit-transparency rule} 00 FF 90 40 DB 90 5D 90 10 40 5B 5D 10 77 34 1D A9 F2 {framing} C0 00 FF 90 40 DB 90 5D 90 10 40 5B 5D 10 77 34 1D A9 F2 C0 {hdx} C0,00,FF,90,40,DB,90,5D,90,10,40,5B,5D,10,77,34,1D,A9,F2,C0,DD,DD,DD,DD,DD, Contact REM at MIT-MC for additional PCNET test data.  Date: 19 September 1982 08:55-EDT From: Robert Elton Maas Subject: SDLC CRC installed in PCNET protocol To: PCNET-PROTOCOL at MIT-MC cc: TVR at SU-AI, Danielson at PARC-MAXC I've installed the new SDLC CRC code in PCNSR6, and tested it using (TEST5) and (UNTEST5) in 8-bit transparent mode (using hexadecimal interface) with all protocol upgrades in effect. It seems to work. Now I need somebody else to check this against our protocol document to verify the two agree exactly. Any volunteers?  Date: 19 September 1982 07:42-EDT From: Robert Elton Maas Subject: SDLC CRC working at long last! To: PCNET-PROTOCOL at MIT-MC cc: Danielson at PARC-MAXC Danielson at PARC-MAXC supplied some test data from a SDLC-CRC chip on some device controller, and also supplied a couple of MESA functions that implemented the computation of SDLC CRC. I translated the MESA into LISP, and added a toplevel function for transmitting (complements the CRC and appends the two bytes of it to the end of the block) and for receiving (just call the CRC on the whole block including transmitted CRC, no special stuff, you should always get hexadecimal F0B8 if a good block is received). Well, it works!! It agrees 100% with the test data from the SDLC chip, and the result on all test data plus some I created myself gives F0B8, which is the same constant in the Computer Design article we received a year or two ago. It would be nice to get some additional independent check that we're computing the right CRC, but for now I'll just assume we are, and install this as upgrade number thirteen (hexadecimal "D") in my PCNSR6 program, corresponding to protocol revision number thirteen from our meeting of a year ago (see the SU-AI file AGENDA.81A[1,REM] for complete list of proposed protocol changes, some of which are now done).  Date: 18 September 1982 21:20-EDT From: Robert Elton Maas Subject: Re: PCNET urgent CRC query -- some progress To: Danielson at PARC-MAXC cc: PCNET-PROTOCOL at MIT-MC, RWG at MIT-MC, TVR at SU-AI Well, the MESA algorithm you sent me, translated to LISP, seems to give the result you claimed it did. See LISP transcript below. ;Output base is hexadecimal, prefixed by "+" to indicate the things ; printed are numbers even if they start with letters A,B,C,D,E,F. (GRINDEF CRCBIT) (DEFUN CRCBIT (CRC BIT) (SETQ CRC (LXOR CRC BIT)) (COND ((NOT (ZEROP (REMAINDER CRC +2))) (LXOR (LSH CRC -1) +8408)) ((LSH CRC -1)))) (GRINDEF CRCBYTE) (DEFUN CRCBYTE (CRC BYTE) (DO ((BITNUM +0 (ADD1 BITNUM))) ((GEQ BITNUM +8)) (SETQ CRC (CRCBIT CRC (REMAINDER BYTE +2))) (SETQ BYTE (LSH BYTE -1))) CRC) ;Change output base to octal so you can see that octal constant in the ; form you gave it to me. (SETQ BASE 8.) 10 ;No matter what base you are in, that base itself always prints as ;"10", i.e. one of the base plus zero ones, so don't let that confuse you. (GRINDEF CRCBIT) (DEFUN CRCBIT (CRC BIT) (SETQ CRC (LXOR CRC BIT)) (COND ((NOT (ZEROP (REMAINDER CRC 2))) (LXOR (LSH CRC -1) 102010)) ((LSH CRC -1)))) ;Change output base back to hexadecimal for the test run. (SETQ BASE 16.) +10 ;If base is larger than ten, a "+" is prefixed to distinguish ;hexadecimal or other numbers from words. (CRCBIT 177777 0) ;Input base is still octal (don't be confused). +FBF7 ;With first zero bit accumulated (CRCBIT * 0) +F9F3 ;With second zerobit accumulated (CRCBIT * 0) +F8F1 (CRCBIT * 0) +F870 (CRCBIT * 0) +7C38 (CRCBIT * 0) +3E1C (CRCBIT * 0) +1F0E (CRCBIT * 0) +F87 ;With all eight zero bits accumulated ;Now let's do all eight bits of a byte in one command... (CRCBYTE 177777 0) +F87 ;Now let's do a second byte of zeroes... (CRCBYTE * 0) +F0B8 ;Hey, it works! More later. I need a nap now. After my nap I'm gonna try to figure out why my original LISP program dosn't get the same result (not even with bits reversed).  Date: 17 September 1982 06:23-EDT From: Robert Elton Maas Subject: New test data To: PCNET-PROTOCOL at MIT-MC I've improved my PCNSR6 program to be able to trace all lower levels of protocol at the same time, nicely formatting them including names of layers between the data that is passed at interfaces. This may be useful for understanding the lower levels of PCNet protocol. (David Harris, you may want to snarf this into the document en masse then edit it a little later.) I created three examples, one in Radix-41 and two in binary (but with alternating checksum since I don't yet have SDLC CRC working). The file at present is only about 2k bytes, so here it is en masse: This file consists of examples of various levels of PCNET protocol, individually and together. Data is shown in hexadecimal, two characters per data byte, but where it's all text that's shown also, off to the right. Example of data passing thru levels 1 (HDX), 2 (Framing), 3 (R41 chars), 4 (41<=>256 base), 5 (Validation). We assume "Test" with zero parity occurs as data, the packet is being sent from the originate node, the sequence (GIVE) number is 3, and the WANT number is 5. GIVE=3, WANT=5 is impossible in simple mode, but we use it here to illustrate the placement of the fields: Test SEQ=3 WANT=5 54 65 73 74 {validation} 54 65 73 74 1D 27 18 00 {256/41 base} 0C 22 27 11 17 24 04 12 01 03 1A 23 {m41/r41 chars} 3C 54 59 43 49 56 34 44 31 33 4C 55 {framing} 40 3C 54 59 43 49 56 34 44 31 33 4C 55 40 {hdx} C0 BC D4 D9 C3 C9 D6 B4 C4 B1 B3 CC D5 C0 DD DD DD DD DD @ Subject: first reading of new document done now (LONG MSG, 11.3K BYTES) To: G.Harris at SU-SCORE cc: PCNET-PROTOCOL at MIT-MC Preliminaries: I've received a new draft of the introductory PCNET document, formerly PCNET;INTRO >, and reviewed it. Fylstra and two others have also received it and can make sense of my page references etc. below. Others may choose to ignore this message or just sort of browse it for a general impression, or may want to ask David Harris for their own copy. However I think (see below) the document has enough rough edges that four people reviewing it at this time are quite enough. No point burning the rest of you out on this, rather let's save the rest of you-all for the next edition, after the four of us are burned out, so you can give it a fresh review. Ok? Now on with my review... I have many comments. There are probably many thing missing, but I didn't notice them much. It needs lots of examples (perhaps each level of protocol should have an example showing just that level in vacuuo, i.e. what gets passed to it and what comes out on the other side; then each server should have a complete PREAD/PWRITE-level transcript showing a whole session in which node ID's are exahcnged and that server is called and does its repertory of tasks then it exits and the nodes also exit&hangup; then one final transcript showing a session in which several servers are used). Of course the examples in old protocol need upgrading. Also, the table of opcodes needs upgrading for opening programs by name (upgrade number 5)!! It also needs all the dangerous mode change stuff from one of my protocol-meeting agenda&minutes reports. The modem-interface section maybe should have a few more of the high-level functions that are useful in PCNET,such as S1WBT, R7WBT, S1WST, S1AST, ... The section from page 31 thru 33 is very crufty! Several things are used the first time before they are explained, and/or explained in a restrictive way in one section even though they are used in other contexts in other sections of the document too. Otherwise, only somebody who is trying to learn the protocol from this document in vacuuo would be able to identify what else is missing or not explained sufficiently. Now for the little errata and specific comments not covered in the general remarks above: (page number in September 16 edition) (ii) IV. Maybe each app'l program should be documented separately (in a separate major section, the way for example TELNET and SRCCOM are documented separately in a TOPS-20 manual), clearly documenting the private protocol each of them uses for talking to its alter-ego on the othe node, with a full scenerio example shown using the G:STUBS mode in PCNSR6. (2) You talk as if electronic mail is almost always forwardable whereas electronic file is almost never, with just the slightest mention of the exceptions. I'd prefer distinguishing message-style simplex store-and-forwardable ("connectionless"; current Internet jargon) communication, from duplex end-to-end-connection non-forwardable realtime-negotiable communication; then separately distinguishing electronic mail (usually natural-language text but with possible graphics) addressed to people or their mailboxes, from files (often source or object programs) addressed by specific program or document name and file type; then indicating that it's most customary to use connectionless mode for mail and end-to-end-connection for files but PCNET supports all four combinations. (4) Re sharing of phone: This is a general problem with any phone-based computer network. You should mention this problem is orthogonal to the decision of what protocol to use except for initial connection (hello) negotiations (i.e. negotiate whether voice or data if the line is shared). (4) Re negotiating number of data bits and stop bits: I think we will stick to 1 start + 8 data + 1 stop for the standard version, no need to negotiate this on each connection, huh? (6) Re 'whether to send an "end" marker after the data': This is a good explanation! Although it lies slightly technically, the logical effect is exactly as you worded it, which is better than the technical ways I previously worded this same statement. (7) "(see interim mail protocol)" needs to be flushed. Refer to section of this document instead. (8) Re "asking for ECHO or MAIL1": we should include "or any other program". (8) Re "Please-Do Open-Streams (C0+04 = C4)": this system of 2+6 bits is used before it's defined (page 11). (8) Re 'O-->A Stream=0 EOD: C4 01 "MAIL1"': again this notation is used before it's explained (pages 8-9). (8) "always 40 in simple mode": Correction, 41 (hexadecimal), i.e. logical stream 1 with reserved 40 bit on (to indicate that originate node requested and answer node granted the stream). (8) "2 for MAIL1": That was the old protocol befor GNU added a third stream for a text reply "GOOD: Thanks" or "BAD: Can't understand header". Now it uses 3 instead of 2 streams. (9) "only 2 channels": 3 now. (10) "In simple mode there is no way to get out of the ECHO program ...": As implemented on my PCNSR6 node, at least I think it's this way, you get out of ECHO by sending EOD bit on any channel it is using. The ECHO interprets that bit as "bye now, return to node-control program". I prefer this protocol to what you've documented. Ok? (10) 2.2.1.6 MAIL1 PROGRAM ... You're mixing simplex (connectionless) and duplex (end-to-end-connection) protocols in this description. I'm pushing for keeping the two kinds of protocol in separate applications programs, MAIL1 for connectionless and FTP1 or MAIL2 or some other name for end-to-end-connection protocol. Of course we might end up with all this in one "application program" after all, except later in the document you talk of two different programs, MAIL1 and FTP1. I guess the protocol committee must make this decision before documentation of MAIL1 et al can proceed much further. (10) Footnote #7: This has indeed been written online, in APPPRG.PRO. Maybe you have an old version of this file? (11) "Beyond the scope of this document": Most of the general stuff is now in this document, in the MODEMI section. It doesn't go into details of how various modems are controlled, but it has the generic functions called from PCNET to accomplish dialing etc. (11) "I won't" etc. method using 2+6 bits: This should be defined earlier, since it's used earlier, and it should be explained that although it was designed for talking to the node-control process this same method is reccommended for various applications programs and in fact is used in the MAIL1 protocol. (11) "if a PCNet node receives a control message" should read "if the node-control process or any application program using this method receives a message which has the next-to-high-order bit set, i.e. either a 'Please-Do' or a 'I-Will'". (12) opcode table is for workshop-watered interim-mail-protocol, needs complete revamping. (12) "-1-- ----": you might mention this bit is the hex 40 offset for stream numbers mentionned earlier. In advanced nodes where the answer node can invoke application programs in the originate node (the opposite of what is allowed in simple nodes), this will be 0 in such cases to indicate the originate node instead of the answer node granted the request. In full-duplex where requests in both directions may occur at the same time, this "who-allocated" distinction is essential to prevent different processes from allocating the same stream; i.e. originate allocates in block -0xx xxxx while answer alocates in block -1xx xxxx. (12) "this is just the information ... passed to PWRITE": you might also say "and then passed from PREAD to the corresponding program on the other node". (15) 'same as ... "SDLC" or "X.25": Let's try to confirm the two really do use exactly the same polonomial and conventions for initialization and inverting bits. I think they use the same polynomial but not the same init or inversions, thus our statement is false. But I am not sure, this info is second hand. (16) "WEGIVE is compard to the 3-bit GIVE field...": I think "GIVE" should read "WANT". Right? (16) "When ... received ..., its number is compared to WEWANT ..": Insert the word "GIVE" before the word "number". Right? (16) "WEWANT is copied into all transmitted blocks ..": before the word "all" insert "the WANT field of". (21) 2.6.1.2 first paragraph re CR for IBM: "Robustness" is the wrong word here. In fact use of instead of 3-of-5 brackets makes it LESS not more robust, but it makes it MORE general, allowing talking to crufty HDX line-oriented systems such as IBM 360/370/3033. The second paragraph however makes it MORE robust (but not on HDX line-oriented systems of course). Minor rewording? (22) 'begins with the first non-"@" received, and ends with the following "@" or bracket': before the word 'following' insert the text 'last character before the'. I.e. exclude both start and end atsign from the body of the block being processed via R41 or binary transparency. (26) (bb) should also include answering the phone after it rings and putting up your carrier, then waiting a few seconds, detecting remote carrier. (26) Although technically the UART (ISTRR et al) and the modem (ISTCA et al) are separate devices, it's slightly confusing to say only ring-detect and carrier-detect are needed by PCNET since in-data-available and out-data-buffer-free (UART signals) are also needed. Perhaps we should say those two are the only needed from the modem per se, and the only other signals needed are ISTRR and ISTTR from the UART? Then we can proceed into the section that defines primitives for BOTH modem and uart. (26) Table of verbs: include R7W and S1W ? Maybe even S1A? (26) Table of nouns: include ST ? (28) 30 seconds timeout standard for carrier: PMMI modems are hardwired to use 17 seconds, no more, no less. If you tell it something more, it wastes the rest of the time. If you tell it something less, it holds the full 17 but wastes the difference between what you say and what it wants. (Or something weird approximately that). The best you can do is delay a few seconds BEFORE starting the 17-second window. You still get 17 seconds, but they start later. Do other modems have similar restrictions? Perhaps our reccommended 30 should be changed to a smaller value, like 17, in the light of an apparent industry standard? (29) Include S1WBT, R7WBT, S1WST, S1AST ? (30) Need upgraded examples!! (31) CRC16 for 6800: With "40" changed to "08", does this now work? Has anybody actually made it work as modified to be sure we aren't as confused as before? Can somebody create test data with this modified algorithm which I can compare with my LISP version? (37,38,40,43) Random suggestions for upgrading the protocol, but not urgent. (43) "Protocol Writeup #2": This used the old protocol you saw in my 1977 SAIL program. It's totally obsolete except for some very high level prose like 4.5 billion humans, 0.5 billion with telephones, all 0.5 billion of which might be on PCNet.  Date: 16 September 1982 07:02-EDT From: Robert Elton Maas Subject: PCNSR6 now has 8bit transparency mode! To: PCNET-PROTOCOL at MIT-MC Thanks to the hexadecimal-debugging mode I installed earlier tonite (see earlier message to INFO-PCNET), I found it possible to install 8-bit mode in PCNSR6 and indeed did so and apparently have it working now. The only part of 8-bit mode as defined in our current protocols that I don't have implemented is CRC, so for now you're stuck with alternating checksums (the standard for Radix-41) if you use my program. Anyone familar with PCNET protocol care to play with my program to verify it correctly implements what we've documented it should? (For those of you afraid 8-bit mode is another month of work; I did both the hexadecimal debugging mode and 8-bit mode in one night!)  Date: 15 September 1982 05:32-EDT From: Robert Elton Maas Subject: First message, mail/ftp protocols To: PCNET-PROTOCOL at MIT-MC (1) This is the first message to the new PCNET-PROTOCOL mailing list since I reconstituted it yesterday and today. It consists of a retransmission of a message I sent to Harris and Fylstra yesterday, plus some preface for the benefit of those of you who don't know what we're up to yet having missed earlier messages and also for the purpose of formally introducing the topic under discussion. (2) If any of you want to send to all the PCNET-PROTOCOL directly, just send to PCNET-PROTOCOL at MIT-MC. If you'd rather have me check your message for spelling errors and obvious misunderstandings and then re-send it after I edit it, then send it just to me and I'll get around to it within 24 hours (usually sooner). Those of you who haven't been in these recent discussions and don't really understand what we've been discussing, I prefer you send it thru me rather than directly. (3) David Harris says he'll have a new draft of the main protocol document (currently PCNET;INTRO >) for me to review in a few days. I'll have more to say on the current state of our protocol documentation after I have seen the new draft protocol document. (4) The major topic of discussion at this time, and the subject of the remailed message that follows, is whether our FTP/MAIL protocol specifications are satisfactory, and if not what needs to be added. Mr. Fylstra has convinced me that we need something not previously present, namely a way to distinguish between text and image mode when sending/receiving files. I think the first thing to decide when actually designing the protocol is whether message-style service (as described in PCNET;SERPRO TTY) or end-to-end-style service or both are to be provided. If both, then should they be in the same "applications program" (formerly called "server process"), or in separate "applications programs". My opinion is that we should define protocols for both modes of service, even if most nodes won't implement both, and that they should be in separate "applications programs". The rest of this message is my argument for them being separate. Date: 14 September 1982 11:31-EDT From: Robert Elton Maas Subject: PCnet text/image, additional arguments To: G.HARRIS at SU-SCORE, fylstra.tsca at SRI-UNIX cc: REM at MIT-MC At this time, I'd like to state additional arguments in favor of keeping two different "application programs", MAIL1 for message-style sending of electronic mail and files and requests for mail&files etc., and FTP1 or somesuch for end-to-end types of mail/file interactions. The runtime environment of the two modes are quite different. MAIL1 accepts things blindly. It can simply spool everything off to magnetic tape and then process it later. It has to know about forwarding, hence latitude&longitude, but this can be offline. FTP1 can't forward at all, thus doesn't have to know about latitude&longitude. But it does have to know about the disk system, including local mailboxes, in order to properly accept or reject or retrieve mail/files, and this all has to be online at the same time as connection. A node may choose to use different methods for the two modes of operation, for example interacting directly with the file system for FTP1 (refusing to accept the file if the file system is full) but spooling everything off to magtape for MAIL1. This would have the advantage that messages too big for the file system can still be forwarded for a third party, and even a small file being forwarded doesn't take up any disk space even temporarily. Trying to cram both direct file access an magtape spooling into a single application program may be inadvisable. Trying to document both modes in a single application program may be difficult for people to understand. Thus I propose separating the two modes: MAIL1 -- The stuff described in SERPRO TTY, which is partly implemented in MAIL1 in my LISP program. Message-style simplex forwardable data with no need for end-to-end on-the-fly feedback. FTP1 -- The kind of stuff conventional CP/M and other FTP programs do. End-to-end duplex interaction negotiating filenames/mailboxes, with no forwarding possible due to need for end-to-end feedback. Note that binary files can be sent message-style using MAIL1, it's just that because of possible forwarding you can't be sure the message got thru (just like Arpanet mail, a few days later you may get a barfback saying the message couldn't be delivered). Also mail can be sent and received using FTP1, it's just that you need a direct connection between sender and recipient. But most of the time MAIL1 would be used for electronic mail while FTP1 would be used for exchanging files.