The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1982)
DOCUMENT: TCP-IP Distribution List for February 1982 (4 messages, 12946 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1982/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 1982
From:      TCP-IP at BRL
To:        TCP-IP at BRL
Subject:   TCP-IP Digest, Vol 1 #14
TCP/IP Digest            Thursday, 4 Feb 1982      Volume 1 : Issue 14

Today's Topics:
               Digest Mail Input  &&  TCP/IP Press Package
                         Protocol Documents List
                 ArpaNet Link -vs- Message-ID and TCP/IP
       FTP Server Replies and Commands  &&  TCP/IP for the Cybers
                   Introduction to Networking Pointer
                        SMTP Protocol Discussions
                    *Spoiler*  DECNET and UNIX Survey
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

To: TCP-IP@BRL
Subject: Digest Mail Input

   The address for submissions to the Digest is:

	   TCP-IP@MIT-AI			(ARPAnet)
	   !menlo70!hao!brl-bmd!tcp-ip		(UUCP/USEnet)

   Requests, problems, or discussions with the Moderator not to be published
   in the digest can be sent to:

	   TCP-IP-REQUEST@MIT-AI		(ARPAnet)
	...!menlo70!hao!brl-bmd!tcp-ip-request	(UUCP/USEnet)

   ARPAnet mail may also be sent to those same addresses at
   BRL (i.e. TCP-IP@BRL).


A message sent to TCP-IP-Request was mistakenly published in Vol 1 #13.
This will not happen again.  I regret any inconvienience this
may have caused.
				-Mike

------------------------------

From: Mike Muuss <Mike@BRL>
Subject: TCP/IP "Press Package"

Einar Stefferud <Stef@KA> and Vint Cerf <Cerf@usc-isi> have come up with
the idea of putting together a TCP/IP "Press Package" which we could feed
to Datamation and IBM and everybody else who ought to hear about TCP/IP,
but maybe hasn't.  This would be mostly a cut-and-paste job done to some
of the existing RFCs and IENs, along with descriptive text from previous
digests, and new contributions.  If you submitted something which was
published in a previous digest, and you would not mind having it become
part of the Press Package, please send me a note -- only contributions
specifically designated for public distribution will be included in
the press package.  The same holds true for all new submissions to the
Digest.  Only clearly marked letters will be added to the press package
file;  all others go to the digest only.

Also, anybody who would like to contribute (USMAIL) addresses of people
who ought to get the press package should send them to TCP-IP-Request.

				Thoughts?
				  -Mike

------------------------------

From: POSTEL at USC-ISIF
Subject: Protocol Documents

It might be helpful to have a list of the documents that specify the
protocols to be used in the TCP environment.

The NCP/TCP Transition Plan                 [RFC 801]
Protocol Documents
   Introduction
      Catenet Model                          [IEN-48]
   Network Level
      Internet Protocol                     [RFC-791]
      Internet Control Message Protocol     [RFC-792]
   Host Level
      User Datagram Protocol                [RFC-768]
      Transmission Control Protocol         [RFC-793]
   Application Level
      Telnet Protocol                       [RFC-764]
      File Transfer Protocol                [RFC-765]
      Simple Mail Transfer Protocol         [RFC-788]
      Trivial File Transfer Protocol        [RFC-783]
      Name Server Protocol                  [IEN-116]
   Appendices
      Assigned Numbers                      [RFC-790]
      Pre-emption                           [RFC-794]
      Service Mappings                      [RFC-795]
      Address Mappings                      [RFC-796]
      Mail Header Format Standards          [RFC-733]

These documents can be copied as public access files from the Network
Information Center Library on the SRI-NIC ARPANET host. The FTP pathname
for a file is <NETINFO>RFCxxx.TXT or <NETINFO>IEN-xxx.TXT where the xxx
is the document number (note the dash in the IEN file names, and no dash
in the RFC file names).  These files can be copied via FTP using the FTP
username ANONYMOUS and password GUEST.

--jon.

------------------------------

From: GEORGE at AFSC-HQ
To: tcp-ip at BRL
Subject: ARPANET "link" vs "message-id"

With a TCP/IP implementation on ARPANET, the use of the "link" field
in the 1822 leader to identify Internet Protocol precludes the use of
the "message-ID" field for multiplexing independent data streams
between hosts.  It seems that we're reduced to a send message -- wait
for RFNM (or msg type 7-9) before another message can be sent to the
same host.  An alternative, of course, is to ignore RFNM's and let the
higher-level TCP layer handle all retransmissions and let the local
IMP block output from the host after 8 messages.  Am I missing something
or is there to be an RFC replacing the Report 1822 (May 1978 revision)?
   
C K Norris, SAMNET Software Development Group, Eglin AFB 
            mail addr : George @ AFSC-HQ

------------------------------

From: GEORGE at AFSC-HQ
To: Tcp-ip at BRL, postel at ISIF
Subject: FTP server replies/ (commands)

It appears that most server FTPs use a "255 SOCK port no." reply (command ?).
Where is this documented? I see no mention of this command in RFC764 nor
in the older RFC542 (Arpanet Protocol Handbook, NIC 7104-jan78).
 
The Air Force Systems Command FTP server (SAMNET) for PDP11 RSX11M also
issues the "255 SOCK port no." but always for the default port no. SAMNET
user FTP, assuming all servers will speak on the default port, issues
his "ACCEPT CONNECTION" for the server default port (actually before
issuing his STOR or RETR). FTP servers, such as UNIX and more recently
TOPS20, which issue the SOCK reply (COMMAND ?) for other than the default
port cause us problems. ( SAMNET user FTP times out--DATA connection not
established--).
 
After studying RFC793 (TCP) and RFC764 (FTP) , I am concerned this problem
will follow us to TCP/IP. Is there an RFC that describes "SOCK". 
My interpretation of RFC764 is - server FTP does not issue Commands only
replies and is therefore bound to speak on the DEFAULT PORT. I would
appreciate some comments from the ARPANET community and Protocol designers
on this subject.
 
Regards, 
 
Calvin George
USAF AD/KRESS
EGLIN AFB,FL. 32542 

------------------------------

From: POSTEL at USC-ISIF
Subject: re: FTP commands and replies
To:   George at AFSC-HQ
cc:   postel at ISIF, tcp-ip at BRL

Calvin:

Nice to hear from you, and learn of your interest in FTP. You concern for
function to switch off the default data socket (or port in TCP) is well taken,
it is an important function.

I think you had a typo in your message.  You referred to RFC 764 as being
the FTP document for use of FTP on TCP.  Actually the FTP document is
RFC 765 (RFC 764 is the Telnet document).

In RFC 765, there is both a PORT command, and a 227 reply, to support the
selection of a non-default data connection.  There is a brief example of
the scenario on page 41.

You are correct in suggesting that there have been implementation problems
with this procedure in the past.  I think the new description (in RFC 765)
is clear enough that much of the past misunderstandings can be eliminated.

In fact, the documentation of the old NCP based FTP is in a poor state. This
is due to the fact that several of the implementations were based on early
versions of the specification and were not updated to match later 
specifications.  A measure of the confusion that existed can be seen from a
review of RFC 691 which compares two sets of FTP reply codes.

We expect that the past confusion and problems can be left behind as we move
to TCP, with a clearer specification of the FTP procedure.

Thanks again for letting me know your concern.

--jon.

------------------------------

From: teklabs!michaele at Berkeley
Subject: TCP in Ratfor

    Mike O'Dell from LBL-UNIX stated that we (teklabs) have written a
TCP in ratfor for Cybers.  That is not quite right.  We have written a
TCP for Cybers in SYMPL (CDC's systems language), a subset of JOVIAL.

    We have been running it for several monbths, and it works well.
Also, Clem Cole in not working at Tek right now, he is attending a
Phd program at Berkely.

Michael Edelman - teklabs!michaele

------------------------------

From: teklabs!michaele at Berkeley
Subject: Teklabs tcp/ip

    It has been stated that Teklab is writing a version of TCP in Ratfor.
That is not true.  Teklabs has implemeted TCP/IP on a Cyber 175. The
TCP is written in SYMPL, CDC's systems language; IP is written in PP
assembler.  Teklabs is in the process of implementing TCP/IP for VMS and
TOPS.  The TCP is being written in BLISS, and IP will be written in the
appropriate assembler.

    The Cyber version of TCP/IP has been up for several months and works
very well.  The VMS version should be up within a month.  The TOPS version
should be up in about three or four months.  For more information, you can
contact Tim Fallon (Project Leader) at
ucbvax!teklabs!timf, or Rick Krull (implementation programmer) at
ucbvax!teklabs!rickk.

    My familiarity with the network comes from helping Tim and Rick
with The Cyber Systems interface, and doing some small amount of
testing for/with them.

Have a good One!

Michael Edelman
Computer Science Center 50/454
Tektronix, Inc.
P.O. Box 500
Beaverton, OR 97077
503-627-5034

or better yet:  ucbvax!teklabs!michaele

------------------------------

From: cbosg!harpo!floyd!unc!smb at Berkeley
Full-Name: Steven M. Bellovin
Subject: Introduction to Networking

The latest issue of Computing Surveys has a pretty good introduction
to network protocols and the ISO Open System Interconnection model.

------------------------------

From:      Michael Muuss <mike@BRL>
Subject:   Discussion of SMTP in TCP Digest?

	Because SMTP is one of the "protocols" that is comming with
the TCP/IP package, the TCP Digest seems a good place for this discussion.
It certainly will hit all the designers and implementors, which is good.
You should probably CC MSGGroup or HeaderPeople or whoever else seems
appropriate, but I know of no other list that does any better.  (Of course,
there are probably a few lists bouncing around that I have never run into.
If you find a better forum, please let me know).
						-Mike

------------------------------

From: lwa at mit-csr at mit-multics
Reply-to: lwa.INP@MIT-Multics
Subject: Meta-meta-discussion

I agree that the meta-discussion should be moved to a more appropriate
list, although I have no suggestions for which list is appropriate.  I
have found the TCP/IP discussions to be most interesting, as we are
presently implementing (yet another) version of IP and TCP for UNIX
here.

In regard to this, I have a question about the SMTP protocol as documented
in RFC788.  There appears to be no way for the SMTP user process to abort
a transaction once it has begun to send the data portion of a message.  Is
this correct, or am I simply missing something?
					-Larry Allen

------------------------------

From:     Mike Muuss <Mike@BRL>
Subject:  *** Spoiler Warning ***   ---   DECNET and UNIX

Bill Shannon at DEC asked me to publish his UNIX/DECNET Communications Survey
in the digest so that it would reach the most number of people.  In light
of his comments below, I felt that this would not be inappropriate, although
a little off the usual topic.  Networking is networking.

The next two messages are the last in this Digest.  Those of you who who
are not interested in DECNET or UNIX can stop here.
	-Mike

------------------------------

From: decvax!shannon at Berkeley
To: ucbvax!mike at brl, ucbvax!tcp-ip at brl
Subject: Re:  DECnet/Unix Survey

I sent it to tcp-ip so that if you felt it was appropriate you
could include it in the digest.  If you followed any of the
discussion in net.news recently some people have expressed a
concern that Usenet (and even more so Arpanet) is not the right
place to do something like that.  I of course disagree but for
different reasons than most other people.  I think I needed to
emphasize more that the survey was not done by DEC-the-corporation
as a prelude to coming out with a product, but by Bill-Shannon-a-
member-of-the-DEC-Unix-Engineering-Group before I spend my time
working on such a project.  Of course there would be nothing to
prevent DEC from turning it into a product but that was not the
intent.
					Bill

------------------------------

From: decvax!shannon at Berkeley
To: ucbvax!tcp-ip@brl
Subject: DECnet/Unix Survey

The DEC Unix Engineering Group is considering doing some work
to provide some DECnet capability for Unix.  To make sure that
we do something useful (if we do anything!), we'd like to get
some feedback as to what people would like.  A survey form is
included, please return directly to me with your comments. 
Any general interest messages can be sent directly to the net.


					Bill Shannon
					decvax!shannon
					(603) 884-5044


===============================================================================

			DECnet/Unix Survey

1.  Do you require a supported product?  Must it be supported by DEC?

2.  How much would you be willing to pay for both supported and unsupported?

3.  What version(s) of Unix should it run on?  Is VMUNIX enough?  V7?  S3?

4.  Would you be willing to buy hardware (eg, a front end), to support DECnet?

5.  Do you need to talk to all DEC systems, or would VMS be enough?

6.  Is Phase III end-node capability enough, or do you require routing?

7.  What hardware support do you require?  Is DMC/DMR enough?

8.  Is X.25 support required?

9.  Which of the following capabilities do you require: file transfer, mail,
    virtual terminals, transparent remote file access?

10. Should it be integrated with any other Unix networking capability, e.g.,
    Arpanet, uucp, Berknet, or should it be entirely separate?

11. Anything else you would like to say?

Please return to decvax!shannon@Berkeley.

END OF TCP-IP DIGEST
********************

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Fri Feb  5 02:12:22 1982
From:      ucbvax!tcp-ip
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 1 #14

>From TCP-IP@BRL Fri Feb  5 00:32:33 1982
TCP/IP Digest            Thursday, 4 Feb 1982      Volume 1 : Issue 14

Today's Topics:
               Digest Mail Input  &&  TCP/IP Press Package
                         Protocol Documents List
                 ArpaNet Link -vs- Message-ID and TCP/IP
       FTP Server Replies and Commands  &&  TCP/IP for the Cybers
                   Introduction to Networking Pointer
                        SMTP Protocol Discussions
                    *Spoiler*  DECNET and UNIX Survey
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

To: TCP-IP@BRL
Subject: Digest Mail Input

   The address for submissions to the Digest is:

	   TCP-IP@MIT-AI			(ARPAnet)
	   !menlo70!hao!brl-bmd!tcp-ip		(UUCP/USEnet)

   Requests, problems, or discussions with the Moderator not to be published
   in the digest can be sent to:

	   TCP-IP-REQUEST@MIT-AI		(ARPAnet)
	...!menlo70!hao!brl-bmd!tcp-ip-request	(UUCP/USEnet)

   ARPAnet mail may also be sent to those same addresses at
   BRL (i.e. TCP-IP@BRL).


A message sent to TCP-IP-Request was mistakenly published in Vol 1 #13.
This will not happen again.  I regret any inconvienience this
may have caused.
				-Mike

------------------------------

From: Mike Muuss <Mike@BRL>
Subject: TCP/IP "Press Package"

Einar Stefferud <Stef@KA> and Vint Cerf <Cerf@usc-isi> have come up with
the idea of putting together a TCP/IP "Press Package" which we could feed
to Datamation and IBM and everybody else who ought to hear about TCP/IP,
but maybe hasn't.  This would be mostly a cut-and-paste job done to some
of the existing RFCs and IENs, along with descriptive text from previous
digests, and new contributions.  If you submitted something which was
published in a previous digest, and you would not mind having it become
part of the Press Package, please send me a note -- only contributions
specifically designated for public distribution will be included in
the press package.  The same holds true for all new submissions to the
Digest.  Only clearly marked letters will be added to the press package
file;  all others go to the digest only.

Also, anybody who would like to contribute (USMAIL) addresses of people
who ought to get the press package should send them to TCP-IP-Request.

				Thoughts?
				  -Mike

------------------------------

From: POSTEL at USC-ISIF
Subject: Protocol Documents

It might be helpful to have a list of the documents that specify the
protocols to be used in the TCP environment.

The NCP/TCP Transition Plan                 [RFC 801]
Protocol Documents
   Introduction
      Catenet Model                          [IEN-48]
   Network Level
      Internet Protocol                     [RFC-791]
      Internet Control Message Protocol     [RFC-792]
   Host Level
      User Datagram Protocol                [RFC-768]
      Transmission Control Protocol         [RFC-793]
   Application Level
      Telnet Protocol                       [RFC-764]
      File Transfer Protocol                [RFC-765]
      Simple Mail Transfer Protocol         [RFC-788]
      Trivial File Transfer Protocol        [RFC-783]
      Name Server Protocol                  [IEN-116]
   Appendices
      Assigned Numbers                      [RFC-790]
      Pre-emption                           [RFC-794]
      Service Mappings                      [RFC-795]
      Address Mappings                      [RFC-796]
      Mail Header Format Standards          [RFC-733]

These documents can be copied as public access files from the Network
Information Center Library on the SRI-NIC ARPANET host. The FTP pathname
for a file is <NETINFO>RFCxxx.TXT or <NETINFO>IEN-xxx.TXT where the xxx
is the document number (note the dash in the IEN file names, and no dash
in the RFC file names).  These files can be copied via FTP using the FTP
username ANONYMOUS and password GUEST.

--jon.

------------------------------

From: GEORGE at AFSC-HQ
To: tcp-ip at BRL
Subject: ARPANET "link" vs "message-id"

With a TCP/IP implementation on ARPANET, the use of the "link" field
in the 1822 leader to identify Internet Protocol precludes the use of
the "message-ID" field for multiplexing independent data streams
between hosts.  It seems that we're reduced to a send message -- wait
for RFNM (or msg type 7-9) before another message can be sent to the
same host.  An alternative, of course, is to ignore RFNM's and let the
higher-level TCP layer handle all retransmissions and let the local
IMP block output from the host after 8 messages.  Am I missing something
or is there to be an RFC replacing the Report 1822 (May 1978 revision)?
   
C K Norris, SAMNET Software Development Group, Eglin AFB 
            mail addr : George @ AFSC-HQ

------------------------------

From: GEORGE at AFSC-HQ
To: Tcp-ip at BRL, postel at ISIF
Subject: FTP server replies/ (commands)

It appears that most server FTPs use a "255 SOCK port no." reply (command ?).
Where is this documented? I see no mention of this command in RFC764 nor
in the older RFC542 (Arpanet Protocol Handbook, NIC 7104-jan78).
 
The Air Force Systems Command FTP server (SAMNET) for PDP11 RSX11M also
issues the "255 SOCK port no." but always for the default port no. SAMNET
user FTP, assuming all servers will speak on the default port, issues
his "ACCEPT CONNECTION" for the server default port (actually before
issuing his STOR or RETR). FTP servers, such as UNIX and more recently
TOPS20, which issue the SOCK reply (COMMAND ?) for other than the default
port cause us problems. ( SAMNET user FTP times out--DATA connection not
established--).
 
After studying RFC793 (TCP) and RFC764 (FTP) , I am concerned this problem
will follow us to TCP/IP. Is there an RFC that describes "SOCK". 
My interpretation of RFC764 is - server FTP does not issue Commands only
replies and is therefore bound to speak on the DEFAULT PORT. I would
appreciate some comments from the ARPANET community and Protocol designers
on this subject.
 
Regards, 
 
Calvin George
USAF AD/KRESS
EGLIN AFB,FL. 32542 

------------------------------

From: POSTEL at USC-ISIF
Subject: re: FTP commands and replies
To:   George at AFSC-HQ
cc:   postel at ISIF, tcp-ip at BRL

Calvin:

Nice to hear from you, and learn of your interest in FTP. You concern for
function to switch off the default data socket (or port in TCP) is well taken,
it is an important function.

I think you had a typo in your message.  You referred to RFC 764 as being
the FTP document for use of FTP on TCP.  Actually the FTP document is
RFC 765 (RFC 764 is the Telnet document).

In RFC 765, there is both a PORT command, and a 227 reply, to support the
selection of a non-default data connection.  There is a brief example of
the scenario on page 41.

You are correct in suggesting that there have been implementation problems
with this procedure in the past.  I think the new description (in RFC 765)
is clear enough that much of the past misunderstandings can be eliminated.

In fact, the documentation of the old NCP based FTP is in a poor state. This
is due to the fact that several of the implementations were based on early
versions of the specification and were not updated to match later 
specifications.  A measure of the confusion that existed can be seen from a
review of RFC 691 which compares two sets of FTP reply codes.

We expect that the past confusion and problems can be left behind as we move
to TCP, with a clearer specification of the FTP procedure.

Thanks again for letting me know your concern.

--jon.

------------------------------

From: teklabs!michaele at Berkeley
Subject: TCP in Ratfor

    Mike O'Dell from LBL-UNIX stated that we (teklabs) have written a
TCP in ratfor for Cybers.  That is not quite right.  We have written a
TCP for Cybers in SYMPL (CDC's systems language), a subset of JOVIAL.

    We have been running it for several monbths, and it works well.
Also, Clem Cole in not working at Tek right now, he is attending a
Phd program at Berkely.

Michael Edelman - teklabs!michaele

------------------------------

From: teklabs!michaele at Berkeley
Subject: Teklabs tcp/ip

    It has been stated that Teklab is writing a version of TCP in Ratfor.
That is not true.  Teklabs has implemeted TCP/IP on a Cyber 175. The
TCP is written in SYMPL, CDC's systems language; IP is written in PP
assembler.  Teklabs is in the process of implementing TCP/IP for VMS and
TOPS.  The TCP is being written in BLISS, and IP will be written in the
appropriate assembler.

    The Cyber version of TCP/IP has been up for several months and works
very well.  The VMS version should be up within a month.  The TOPS version
should be up in about three or four months.  For more information, you can
contact Tim Fallon (Project Leader) at
ucbvax!teklabs!timf, or Rick Krull (implementation programmer) at
ucbvax!teklabs!rickk.

    My familiarity with the network comes from helping Tim and Rick
with The Cyber Systems interface, and doing some small amount of
testing for/with them.

Have a good One!

Michael Edelman
Computer Science Center 50/454
Tektronix, Inc.
P.O. Box 500
Beaverton, OR 97077
503-627-5034

or better yet:  ucbvax!teklabs!michaele

------------------------------

From: cbosg!harpo!floyd!unc!smb at Berkeley
Full-Name: Steven M. Bellovin
Subject: Introduction to Networking

The latest issue of Computing Surveys has a pretty good introduction
to network protocols and the ISO Open System Interconnection model.

------------------------------

From:      Michael Muuss <mike@BRL>
Subject:   Discussion of SMTP in TCP Digest?

	Because SMTP is one of the "protocols" that is comming with
the TCP/IP package, the TCP Digest seems a good place for this discussion.
It certainly will hit all the designers and implementors, which is good.
You should probably CC MSGGroup or HeaderPeople or whoever else seems
appropriate, but I know of no other list that does any better.  (Of course,
there are probably a few lists bouncing around that I have never run into.
If you find a better forum, please let me know).
						-Mike

------------------------------

From: lwa at mit-csr at mit-multics
Reply-to: lwa.INP@MIT-Multics
Subject: Meta-meta-discussion

I agree that the meta-discussion should be moved to a more appropriate
list, although I have no suggestions for which list is appropriate.  I
have found the TCP/IP discussions to be most interesting, as we are
presently implementing (yet another) version of IP and TCP for UNIX
here.

In regard to this, I have a question about the SMTP protocol as documented
in RFC788.  There appears to be no way for the SMTP user process to abort
a transaction once it has begun to send the data portion of a message.  Is
this correct, or am I simply missing something?
					-Larry Allen

------------------------------

From:     Mike Muuss <Mike@BRL>
Subject:  *** Spoiler Warning ***   ---   DECNET and UNIX

Bill Shannon at DEC asked me to publish his UNIX/DECNET Communications Survey
in the digest so that it would reach the most number of people.  In light
of his comments below, I felt that this would not be inappropriate, although
a little off the usual topic.  Networking is networking.

The next two messages are the last in this Digest.  Those of you who who
are not interested in DECNET or UNIX can stop here.
	-Mike

------------------------------

From: decvax!shannon at Berkeley
To: ucbvax!mike at brl, ucbvax!tcp-ip at brl
Subject: Re:  DECnet/Unix Survey

I sent it to tcp-ip so that if you felt it was appropriate you
could include it in the digest.  If you followed any of the
discussion in net.news recently some people have expressed a
concern that Usenet (and even more so Arpanet) is not the right
place to do something like that.  I of course disagree but for
different reasons than most other people.  I think I needed to
emphasize more that the survey was not done by DEC-the-corporation
as a prelude to coming out with a product, but by Bill-Shannon-a-
member-of-the-DEC-Unix-Engineering-Group before I spend my time
working on such a project.  Of course there would be nothing to
prevent DEC from turning it into a product but that was not the
intent.
					Bill

------------------------------

From: decvax!shannon at Berkeley
To: ucbvax!tcp-ip@brl
Subject: DECnet/Unix Survey

The DEC Unix Engineering Group is considering doing some work
to provide some DECnet capability for Unix.  To make sure that
we do something useful (if we do anything!), we'd like to get
some feedback as to what people would like.  A survey form is
included, please return directly to me with your comments. 
Any general interest messages can be sent directly to the net.


					Bill Shannon
					decvax!shannon
					(603) 884-5044


===============================================================================

			DECnet/Unix Survey

1.  Do you require a supported product?  Must it be supported by DEC?

2.  How much would you be willing to pay for both supported and unsupported?

3.  What version(s) of Unix should it run on?  Is VMUNIX enough?  V7?  S3?

4.  Would you be willing to buy hardware (eg, a front end), to support DECnet?

5.  Do you need to talk to all DEC systems, or would VMS be enough?

6.  Is Phase III end-node capability enough, or do you require routing?

7.  What hardware support do you require?  Is DMC/DMR enough?

8.  Is X.25 support required?

9.  Which of the following capabilities do you require: file transfer, mail,
    virtual terminals, transparent remote file access?

10. Should it be integrated with any other Unix networking capability, e.g.,
    Arpanet, uucp, Berknet, or should it be entirely separate?

11. Anything else you would like to say?

Please return to decvax!shannon@Berkeley.

END OF TCP-IP DIGEST
********************

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 1982
From:      TCP-IP at BRL
To:        TCP-IP at BRL
Subject:   TCP-IP Digest, Vol 1 #15
TCP/IP Digest             Monday, 15 Feb 1982      Volume 1 : Issue 15

Today's Topics:
                   ArpaNet LINK -vs- Message-ID Fields
                           SMTP Abort Answered
                   Escape Character in SMTP Addresses?
                   Validation of Reverse Path in SMTP?
                Documentation of TCP/IP as a DoD Standard
                        TCP/IP on Univac Systems?
----------------------------------------------------------------------
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From: POSTEL at USC-ISIF
Subject: re: ARPANET "link" vs. "message-id"
To:   George at AFSC-HQ
cc:   TCP-IP at BRL

C. K. Norris:

The link field is defined to be the high-order eight bits of the twelve 
bit message-id field defined in the 1822 protocol.  The link field is 
used to distinguish between different host level protocols used in the 
ARPANET (e.g., NCP, IP, NVP; see RFC 790 page 10).  IP uses link 155 
(decimal).  

In the normal case the the low-order four bits of the message-id field 
are sent as zeros and are ignored on reception.  Several times in the 
past the idea of using those bits to identify specific messages has been
put forward (e.g., RFC 534, RFC 663), but there has not been a real 
requirement for that level of error control (the ARPANET is very 
reliable).

There is a misconception in your message about the "IMP Blocking".  The 
IMP will block the transmission of a message to a destination host when 
ever there are eight messages in transit to that particular host.  That 
is, the blocking is on a source host to destination host pair basis, and
independent of what links or message-ids or higher level protocols are 
used.  Also, please note, that the eight messages in transit is an upper
bound, and that the IMP may block the host at a lower number if 
resources are not available.  Once a host is blocked, it can't send 
messages to any destination.  The block is cleared when one of the in 
transit messages is delivered and the RFNM (or other response) is 
returned, or more IMP resouces become available.

A proposal for a more flexible interface called "1822L" has been 
circulated as RFC 802 (Nov-81).  The 1822L interface provides for a 
"short-blocking" operation, and for logical addressing in the ARPANET.  
My understanding is that BBN is currently implementing this proposal, so
any comments should be sent to the author (Malis@BBN-UNIX) at once.

RFCs may be copied from the Network Information Center online library at
SRI-NIC via FTP using the FTP username ANONYMOUS and password GUEST.  
The file pathnames are of the form <NETINFO>RFC802.TXT.  Unfortunately, 
some old RFCs are not online any more and some old old RFCs never were. 
If you really need a RFC that is not online send a message to 
NIC@SRI-NIC requesting what you need.

--jon.

------------------------------

From: POSTEL at USC-ISIF
Subject: re: SMTP Abort
To:   lwa.INP at MIT-MULTICS
cc:   TCP-IP at BRL

Larry Allen:

You are correct.  There is no way in SMTP to cancel the message once the
DATA command is issued.  The only way out is to break the connection.

This is true in the current ARPANET mail system, and I am not aware that
any serious problems occur brcause of it.

--jon.

------------------------------

From:  Greenwald.INP at MIT-Multics
Subject:  SMTP

	There was recently a discussion about the problems of "@"'s and
"."s in SMTP addresses and routes, and it was considered bad, because some
hosts have special meanings for those characters in user-names or mailboxes.
	Well, no matter what character we pick, some joker will always want
to use it on his system for something special. It seems to me this problem is
understood. Anything in an SMTP route or address is to be interpreted only by
SMTP. If we want SMTP to pass it on to the local system, then we have an SMTP
special character that says just that: quote the next charcetr.
	What is wrong with introducing a quote character into SMTP? In
order for something to be interpreted by a host with  any meaning local to his
system, it must be preceded by the quote symbol. (That includes the quote
symbol!)
	Comments?
	- Mike

------------------------------

Date:  7 February 1982 18:26 est
From:  Greenwald.INP at MIT-Multics
Subject:  Validation of reverse path in SMTP

	I think that SMTP servers should validate the reverse-path before
accepting the MAIL command. Right now there is not really a Reply Code for
that that MAIL expects (501 is sort of right, but we want to give something
that says "Mailbox Syntax Incorrect". Maybe a 553?)
	Anyway, it is useful to check this because you may have to use that
reverse-path, (I mean that's the idea of it, isn't it?), and if it doesn't
mean anything to you then it is useless. The time to check it is when you get
it.
	And yes, I think it possible that you can get badly formed
reverse-paths. I already have. Hosts tack on a local name for themselves at
the end, that we don't understand.
	Any comments?
	- Mike

------------------------------

[ A number of people have enquired about documentation of the fact that
  TCP/IP is a DoD Standard.  Vint Cerf quickly came to the rescue, and
  provided a copy of IEN 152, which contains (in part) two letters which
  give TCP/IP it's official status.  They are reproduced herein (by permission)
  for all to see.  -Mike ]

IEN 152                                                        Vint Cerf
                                                              DARPA/IPTO
                                                               1 July 80
                      DoD Protocol Standardization

The attached memoranda from the Principal Deputy Undersecretary of
Defense for Research and Engineering and from the Assistant Secretary of
Defense (Communications, Command, Control and Intelligence) describe the
DoD plans for standardizing internet protocols.  The first two are the
Internet Protocol and the Transmnission Control Protocol.

The DARPA Internet project will continue to provide technical support
for the DoD standardization effort, including the test and evaluation of
selected proposed standards.

			- - - - - - - - - - - - -

                     THE UNDER SECRETARY OF DEFENSE         23 Dec 78
                         WASHINGTON, D.C. 20301

MEMORANDUM FOR SECRETARY OF THE ARMY
	       SECRETARY OF THE NAVY
	       SECRETARY OF THE AIR FORCE
	       CHAIRMAN, JOINT CHIEFS OF STAFF
	       DIRECTOR, DEFENSE ADVANCED RESEARCH PROJECTS AGENCY
	       DIRECTOR, DEFENSE COMMUNICATIONS AGENCY
	       DIRECTOR, DEFENSE INTELLIGENCE AGENCY
	       DIRECTOR, DEFENSE LOGISTICS AGENCY
	       DIRECTOR, NATIONAL SECURITY AGENCY

SUBJECT:  Host-to-Host Protocols for Data Communications Networks

A number of data communications networks are operating or under
development within DoD, without adequate provisions for
interoperability.  AUTODIN II is expected to become operational during
FY 1980, to provide common-user data communications service for DoD
computer systems and permit a reduction in the number of specialized
data networks.  Plans are under way to incorporate within AUTODIN II
networks such as the WWMCCS Intercomputer Network (WIN), Intelligence
Data Handling System Communications (IDHSC) and the SAC Digital Network
(SACDIN), among others.  Local networks such as the Community On-Line
Intelligence Network System (COINS) and certain tactical networks must
have effective AUTODIN II interfaces.

AUTODIN II will provide connectivity for a wide range of systems, but
the potential for information exchange beyond narrowly defined
communities will be limited without appropriate standards for internet,
host-to-host, terminal-to-host and other protocols.  As the need to
exchange information across network boundaries increases, lack of common
protocols standards will become a formidable barrier to
interoperability.  Techniques in which the protocols of one network are
translated into the protocols of another will become increasingly
unworkable as the number of protocols and networks requiring
interoperation increases.

To insure interoperability of future data networking, I am directing the
adoption of a set of DoD standard host-to-host protocols based on the
Transmission Control and Internet Protocols (TCP/IP version 4) developed
in the DARPA/DCA internetwork community.  DoD requirements for
precedence, security, and community of interest controls will be
incorporated within the standard protocol set.  Use of these protocols
will be MANDATORY for all packet-oriented data networks where there is a
potential for host-to-host connectivity across network or subnetwork
boundaries.  Case-by-case exceptions will be granted only for networks
that can be shown to have no future requirements for interoperability.
Because the host-to-host protocol being developed for AUTODIN II evolved
from an early version of TCP and is unsuitable for internetwork
operation, the AUTODIN II TCP will have to be upgraded to the standard
protocol set.  Recognizing that there may be cost and schedule impacts
on the AUTODIN II program, the Defense Communications Agency should
perform a cost tradeoff analysis to determine the optimum time for this
transition.  DCA should provide the results of this analysis by April
1979.

To address these and future protocol issues and promulgate appropriate
standards, I am forming an OSD Protocol Standards Working Group chaired
by the Director, Information Systems.  I ask each addressee to nominate
a representative.  Names should be provided by 8 January 1979 to LTC
Wilcox (695-3287).  The first task of this group will be to finalize
details of the standard host-to-host protocol set.  Draft specifications
for these protocols will be available in January 1979.  Final
specifications should be distributed by April 1979 following review by
the working group and testing by DCA and DARPA.  At that time, I expect
to promulgate these standards and set dates for their adoption.

The Defense Communications Agency is designated as DoD Executive Agent
for computer communications protocols and will manage the implementation
and development and evolution of standard host-to-host protocols, as
designated by the Protocol Standards Working Group.  The DCA will
forward to this office within 120 days a management plan for carrying
out this role.
                                                       Gerald P. Dinneen
                                                        Principal Deputy

			- - - - - - - - - - - - -

                     ASSISTANT SECRETARY OF DEFENSE             3 Apr 80
                         Washington, D.C. 20301

MEMORANDUM FOR SECRETARY OF THE ARMY
               SECRETARY OF THE NAVY
               SECRETARY OF THE AIR FORCE
               CHAIRMAN, JOINT CHEIFS OF STAFF
               DIRECTOR, DEFENSE ADVANCED RESEARCH PROJECTS AGENCY
               DIRECTOR, DEFENSE COMMUNICATIONS AGENCY
               DIRECTOR, DEFENSE INTELLIGENCE AGENCY
               DIRECTOR, DEFENSE LOGISTICS AGENCY
               DIRECTOR, NATIONAL SECURITY AGENCY

SUBJECT:  Host-to-Host Data Communications Protocols

The revised Management Plan for Standardizatioan of Host-to-Host Data
Communications Protocols (enclosure 1) is approved.  The plan has been
modified to emphasize DCA's direct responsibilities as Executive Agent.

The DoD Standard Transmission Control Protocol and Internet Protocol
Specifications (enclosure 2) are hereby ratified.  Use of these
protocols is MANDATORY for all packet-oriented data networks where there
is a potential for host-to-host connectivity across network or
subnetwork boundaries.  In order to facilitate rapid implementation of
these protocols on DoD networks, the Defense Communications Agency, as
part of its Executive Agent role, will prepare a series of
workshop/seminars and implementation support documents to assist the DoD
activities in implementing these protocols.  The AUTODIN II
implementation of these protocol standards will take place as soon after
AUTODIN II IOC as possible.

I would like to thank all those who participated in the OSD Protocol
Standards Working Group during the past year.  That Working Group is
hereby disestablished and its responsibilities are transferred to the
various DCA panels as defined in the Executive Agent Charter.

                                                       Gerald P. Dinneen
------------------------------

Subject: Sperry Univac TCP-IP Implementation
From: TMPL at BBNG
To: TCP-IP at BRL

I have just learned that we are in the  process  of  implementing
TCP-IP  on  the  Sperry Univac DCP-40 Communications Processor on
behalf  of  NUSC,  for  connection  to  the  ARPAnet,  completion
approximately  January  1983.  I was called by George Blankenship
of our Federal Systems operations in McLean, Va.,  who  has  been
reading  the  Digest.  He would like me to ask the Digest readers
if  anyone  knows  of  anyone  else  (outside  Univac)   who   is
implementing TCP-IP for Sperry Univac systems.

Ted Lee

END OF TCP-IP DIGEST
********************

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 1982
From:      TCP-IP at BRL
To:        TCP-IP at BRL
Subject:   TCP-IP Digest, Vol 1 #16
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
********************

END OF DOCUMENT