----MESSAGE-BEGIN---- <1982020419520000> Mail-from: ARPANET host BRL rcvd at 5-Feb-82 0239-PST Sender: Mike Muuss From: TCP-IP at BRL To: TCP-IP at BRL Date: 4 Feb 1982 Subject: TCP-IP Digest, Vol 1 #14 Via: Brl; 4 Feb 82 23:52-EDT 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 Subject: TCP/IP "Press Package" Einar Stefferud and Vint Cerf 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 RFCxxx.TXT or 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- [anews.Aucbvax.6079] <1982020421122200> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!ucbvax!tcp-ip From: ucbvax!tcp-ip Date: Fri Feb 5 02:12:22 1982 Subject: TCP-IP Digest, Vol 1 #14 X-Google-Info: Converted from the original A-News header >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 Subject: TCP/IP "Press Package" Einar Stefferud and Vint Cerf 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 RFCxxx.TXT or 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982021510040000> Mail-from: ARPANET host BRL rcvd at 15-Feb-82 1720-PST Sender: Mike Muuss From: TCP-IP at BRL To: TCP-IP at BRL Date: 15 Feb 1982 Subject: TCP-IP Digest, Vol 1 #15 Via: Brl; 15 Feb 82 14:04-EDT 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1982022116320000> 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 ******************** ----MESSAGE-END----