TCP-IP Digest Vol. 1 No. 16

eZine lover (@eZine)

Published in 

TCP IP Digest

 · 11 months ago

 
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 
********************