21-Feb-82 20:11:23-PST,5996;000000000001 Mail-from: ARPANET host BRL rcvd at 21-Feb-82 2011-PST Sender: Mike Muuss From: TCP-IP at BRL To: TCP-IP at BRL Date: 21 Feb 1982 Subject: TCP-IP Digest, Vol 1 #16 Via: Brl; 21 Feb 82 20:32-EDT TCP/IP Digest Sunday, 21 Feb 1982 Volume 1 : Issue 16 Today's Topics: TCP-IP for Univac systems Quote Character for SMTP FTP Commands and Replies MCNC Network Suggestions Solicited ---------------------------------------------------------------------- LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Return-path: @COMSAT-DCN7,@DLM-DLM6,Mills@COMSAT From: Mills at COMSAT Subject: TCP-IP for Univac systems To: TCP-IP at BRL The Universtiy of Maryland Computer Science Center is now implementing TCP-IP for the Univac 11xx machines. Currently, they have an IP version running with the DCNET local-network protocol and a TCP/TELNET user interface. TCP itself is only partially complete at this time. Further information can be obtained from Mike Petry (301) 454-2946. Regards, Dave ------------------------------ From: POSTEL at USC-ISIF Subject: SMTP Quote To: Greenwald.INP at MIT-MULTICS cc: Postel at ISIF, TCP-IP at BRL There is a quote character in SMTP, the backslash "\". --jon. ------------------------------ [ The next two letters are a continuation of the discussion between Calvin George and Jon Postel started in V1#15, concerning FTP Commands and Replies. They are published by permission. -Mike ] From: GEORGE at AFSC-HQ Subject: ftp commands and replies I am still concerned that there can be different interpretations of RFC765 (your correction noted) concerning the changing of DEFAULT port numbers. The scenario on page 41 of RFC765 concerns 3rd party transfers. I appreciate the need for the PASV command and 227 reply for 3rd party transfers. In the case of 2 party transfers, I see no requirement (in the protocol specification) for the USER to issue a PASV command to the SERVER, so that the SERVER might have the opportunity to specify a different port for the data connection. By using DEFAULT ports, defined for FTP, it appears to me there is less network overhead establishing connections. I also cannot see that requiring the SERVER to use the DEFAULT port places any undue restrictions on the SERVER, given the way TCP defines a session. My real concern is: Given we (SAMNET) convert our FTP assuming there is no requirement to issue the PASV command (for 2 party xfers) and the UNIX and TOPS20 implementors convert their FTP such that they expect a PASV so they can REPLY with their intended data port-- our current problem may well follow us to TCP. Could it be that I do not understand RFC765 or is there some ambiguity in this area? -Calvin ------------------------------ From: POSTEL at USC-ISIF Subject: Re: ftp commands and replies To: GEORGE at AFSC-HQ Calvin: I think your concern about two-party transfers and the potential for deadlock between a default-only data connection implementation and a non-default-only data connection implementation can be put to rest. The RFC 765 rules require that every implementation operate with the default ports, and that only the user can initiate a change from the defaults. I will put a note in my master copy of the RFC to add a paragraph on page 15 and on page 40 stating this very clearly. --jon. ------------------------------ From: decvax!duke!mcnc!smb at Berkeley Full-Name: Steven M. Bellovin To: decvax!duke!mcnc!tcp-ip@Berkeley Subject: Network suggestions solicited We would like some advice from the networking community out there in TCP-IP land. The Microelectronics Center of North Carolina (MCNC) is in the process of setting up a network to connect the various universities and other institutions that are participants. We would welcome any suggestions about hardware, software, etc., given the rather varied machines to be connected. Configuraton: At MCNC itself are two VAX 11/780s running 4.1BSD UNIX. Currently, there are 9600 baud leased lines to each of the participating institutions (PIs); these lines are used for 8-line statistical multiplexors. We are considering high-speed microwave links to fully interconnect all of the PIs, and would prefer software that would remain usable. UNC has two VAX 11/780s running 4.1BSD, an 11/45 running v7 UNIX, and another 11/45 which will probably run 2.8BSD. The first three machines are in the same room, and are connected by Able Interlinks; the fourth is across the street, and will probably be connected via either an DMR11 over a coax cable, or a 9600 baud asynch line. They are linked by uucp and Purdue EE net connections. Duke has an 11/70 running v7, as well as several smaller 11s. UNC-Charlotte has a pair of 11/40s running v7. NCSU has several VAX 11/780s running VMS and (sometimes) Eunice; an 11/24 acts as a front-end for their terminals via DECnet. NC A&T will soon (imminently) have a VAX 11/780 running 4.1BSD. RTI has an 11/23; it's not clear what system they'll run on it yet. V7 and XENIX are two possiblities. There are plans to get a large number of single-user workstations; these will also need to be tied in to the net. And we'll probably need the ability to talk to IBM systems running MVS and/or VM, and probably other machines as well. We need mail service, remote logins, and both spooled and real-time file transfer. Some of these files will be quite large. We currently use uucp, but it isn't sufficient. Now -- if you had all that hardware, what would *you* do? END OF TCP-IP DIGEST ********************