From jtk at depaul.edu Fri Aug 2 15:38:57 2002 From: jtk at depaul.edu (John Kristoff) Date: Fri, 2 Aug 2002 17:38:57 -0500 Subject: [ih] FTP design Message-ID: <20020802173857.60315c7b.jtk@depaul.edu> The development of ftp over the early years seems to be interesting, although its cumbersome if not difficult for me to put all of the pieces together from the early RFCs, because I wasn't there. Its a subject that came up here and I thought I would see what I could get out of this list. Particularly... Why the design of separate control/data channels, with each typically opening in the opposite direction from the other (not in passive mode). I thought I remember hearing that it had something to do in part because of one particular system's design. Skimming through some of the older RFCs (e.g. 114), it seems originally this was considered but not the preferred method. In the current RFC959 there is mention of having the capability to do full-duplex transfer of data over the data channel, but as far as I'm aware you've only ever be able to 'get' or 'put', but not both at the same time. Was there or is there a system that piggy-backs a 'put' with ACKs if it was doing a 'get' or vice versa? Any additional insights into what might be considered big mistakes in the design with 20/20 hindsight, or collosal mistakes in intentionally leaving something out? John From day at std.com Fri Aug 2 16:42:26 2002 From: day at std.com (John Day) Date: Fri, 2 Aug 2002 19:42:26 -0400 Subject: [ih] FTP design In-Reply-To: <20020802173857.60315c7b.jtk@depaul.edu> References: <20020802173857.60315c7b.jtk@depaul.edu> Message-ID: At 17:38 -0500 8/2/02, John Kristoff wrote: >The development of ftp over the early years seems to be interesting, >although its cumbersome if not difficult for me to put all of the pieces >together from the early RFCs, because I wasn't there. Its a subject >that came up here and I thought I would see what I could get out of this >list. > >Particularly... > >Why the design of separate control/data channels, with each typically >opening in the opposite direction from the other (not in passive mode). >I thought I remember hearing that it had something to do in part because >of one particular system's design. Skimming through some of the older >RFCs (e.g. 114), it seems originally this was considered but not the >preferred method. It was a long time ago. I remember the reason for the separate control and data channels was to ensure that commands could get thru to cancel a transfer and would not be stuck behind half a file. Also, the TIP was a major consideration. TIPs did not have enough memory to implement a user FTP process, so it was the human at the terminal, typing four letter commands. Since TIPs were not the only resource limited systems, there was a definite decision to put most of the burden on the Server. Since the user initiated the command, it could not be certain when the Server would actually post a listen. (On those old timesharing systems, response time was sometimes seconds.) So rather than send another message back to the user (putting more burden on the user), data connections were initiated by the server. I don't remember any OS that forced it into the design. You might note that the RJE protocol was "architecturally elegant" but required the USER to implement an FTP Server, thereby violating the requirement to keep complexity off the user system. This protocol never got much use and the CCN RJE written by Bob Braden was much more successful. > >In the current RFC959 there is mention of having the capability to do >full-duplex transfer of data over the data channel, but as far as I'm >aware you've only ever be able to 'get' or 'put', but not both at the >same time. Was there or is there a system that piggy-backs a 'put' with >ACKs if it was doing a 'get' or vice versa? Remember the original FTP worked with NCP. In NCP connections were half-duplex. As far as I know there is nothing in the protocols to prevent overlapping gets and puts. Implementations may make such a restriction, but there is no reason why not. > >Any additional insights into what might be considered big mistakes in >the design with 20/20 hindsight, or collosal mistakes in intentionally >leaving something out? Not really. We always talked about adding file access (reading or writing parts of a file) and Ken Pogran and I did play with the idea. I wrote an RFC and Ken implemented it. There was much talk about adding all of the various file system commands and some of that was done in other efforts. I think the only real problem, if it were that, would be that had we not had the TIP constraints some things might have been done a little differently. But it would not have been significant change. Actually, I believe that Telnet and FTP got an uncommon number of things right. I think the idea of having replies that were both machine and human readable was brilliant. I forget who came up with it but I think it was Postel and a couple of others. Anyone else's memory better than mine! Take care, John From dpreed at reed.com Sat Aug 3 04:14:50 2002 From: dpreed at reed.com (David P. Reed) Date: Sat, 03 Aug 2002 07:14:50 -0400 Subject: [ih] FTP design In-Reply-To: References: <20020802173857.60315c7b.jtk@depaul.edu> <20020802173857.60315c7b.jtk@depaul.edu> Message-ID: <5.1.1.6.2.20020803070452.03d688d8@mail.reed.com.> I remember all the things you do John (but my connection to the FTP design, pre-internet as it was, was through Ken Pogran, who did the work for it on Multics). I'd just like to add my comment that "separate control and data connections" was hardly a mistake. It was very much on purpose, and for exactly the reason that John points out. Rather than invent a magical "out of band" feature in TCP, which would have multiplied the congestion control complexities, as well as introducing problems of mixing data and control coding schemes, just using two connections was simple. As far as the directionality of streams, one idea that was contemplated was the idea of having control host A create a transfer from host B to host C, while not having a control connection from B to C. Finally, but Ken Pogran can clarify this more if you talk to him, FTP's multiple connection scheme was somewhat hard to implement in Multics security model, but rather than have Multics influence the design, the Multics guys figured out how to generalize the connection notification mechanism to get this to work right. At 07:42 PM 8/2/2002 -0400, John Day wrote: >At 17:38 -0500 8/2/02, John Kristoff wrote: >>The development of ftp over the early years seems to be interesting, >>although its cumbersome if not difficult for me to put all of the pieces >>together from the early RFCs, because I wasn't there. Its a subject >>that came up here and I thought I would see what I could get out of this >>list. >> >>Particularly... >> >>Why the design of separate control/data channels, with each typically >>opening in the opposite direction from the other (not in passive mode). >>I thought I remember hearing that it had something to do in part because >>of one particular system's design. Skimming through some of the older >>RFCs (e.g. 114), it seems originally this was considered but not the >>preferred method. > >It was a long time ago. I remember the reason for the separate control >and data channels was to ensure that commands could get thru to cancel a >transfer and would not be stuck behind half a file. Also, the TIP was a >major consideration. TIPs did not have enough memory to implement a user >FTP process, so it was the human at the terminal, typing four letter >commands. Since TIPs were not the only resource limited systems, there >was a definite decision to put most of the burden on the Server. Since >the user initiated the command, it could not be certain when the Server >would actually post a listen. (On those old timesharing systems, response >time was sometimes seconds.) So rather than send another message back to >the user (putting more burden on the user), data connections were >initiated by the server. > >I don't remember any OS that forced it into the design. You might note >that the RJE protocol was "architecturally elegant" but required the USER >to implement an FTP Server, thereby violating the requirement to keep >complexity off the user system. This protocol never got much use and the >CCN RJE written by Bob Braden was much more successful. > >> >>In the current RFC959 there is mention of having the capability to do >>full-duplex transfer of data over the data channel, but as far as I'm >>aware you've only ever be able to 'get' or 'put', but not both at the >>same time. Was there or is there a system that piggy-backs a 'put' with >>ACKs if it was doing a 'get' or vice versa? > >Remember the original FTP worked with NCP. In NCP connections were >half-duplex. As far as I know there is nothing in the protocols to >prevent overlapping gets and puts. Implementations may make such a >restriction, but there is no reason why not. > >> >>Any additional insights into what might be considered big mistakes in >>the design with 20/20 hindsight, or collosal mistakes in intentionally >>leaving something out? > >Not really. We always talked about adding file access (reading or writing >parts of a file) and Ken Pogran and I did play with the idea. I wrote an >RFC and Ken implemented it. There was much talk about adding all of the >various file system commands and some of that was done in other >efforts. I think the only real problem, if it were that, would be that >had we not had the TIP constraints some things might have been done a >little differently. But it would not have been significant change. > >Actually, I believe that Telnet and FTP got an uncommon number of things >right. I think the idea of having replies that were both machine and >human readable was brilliant. I forget who came up with it but I think it >was Postel and a couple of others. > >Anyone else's memory better than mine! > >Take care, >John > From day at std.com Sat Aug 3 06:45:07 2002 From: day at std.com (John Day) Date: Sat, 3 Aug 2002 09:45:07 -0400 Subject: [ih] FTP design In-Reply-To: <5.1.1.6.2.20020803070452.03d688d8@mail.reed.com.> References: <20020802173857.60315c7b.jtk@depaul.edu> <20020802173857.60315c7b.jtk@depaul.edu> <5.1.1.6.2.20020803070452.03d688d8@mail.reed.com.> Message-ID: At 07:14 -0400 8/3/02, David P. Reed wrote: >I remember all the things you do John (but my connection to the FTP >design, pre-internet as it was, was through Ken Pogran, who did the >work for it on Multics). I'd just like to add my comment that >"separate control and data connections" was hardly a mistake. It >was very much on purpose, and for exactly the reason that John >points out. Rather than invent a magical "out of band" feature in >TCP, which would have multiplied the congestion control >complexities, as well as introducing problems of mixing data and >control coding schemes, just using two connections was simple. Completely agree. Also, in those days FTPs could take awhile and OSs had a tendency to go off and do other things for awhile. So there was a desire to be able to send other commands while the transfer was going on. If for no other reason than to determine that the other end was still thinking about it. > >As far as the directionality of streams, one idea that was >contemplated was the idea of having control host A create a transfer >from host B to host C, while not having a control connection from B >to C. Yes, the third party transfer was part of the spec. > >Finally, but Ken Pogran can clarify this more if you talk to him, >FTP's multiple connection scheme was somewhat hard to implement in >Multics security model, but rather than have Multics influence the >design, the Multics guys figured out how to generalize the >connection notification mechanism to get this to work right. Yea, I vaguely remember that. Was that also related to the convention that the data transfer sockets were a fixed offset from the control (telnet) connection? But I don't remember thinking there were any real "mistakes" with FTP. I remember thinking after we finalized the last version in 73 that we were getting an idea of how to do richer FTP with file access and make file systems more transparent over the net, but that was really icing on the cake. Not really any big insights. I have always contended that the biggest problem with the ARPANet was that we got too much stuff right to begin with!! So that it worked well enough that there wasn't really enough pain to warrant going back to fix it. ;-) To some extent we are paying for that now. Take care, John From jnc at ginger.lcs.mit.edu Sat Aug 3 06:48:23 2002 From: jnc at ginger.lcs.mit.edu (J. Noel Chiappa) Date: Sat, 3 Aug 2002 09:48:23 -0400 Subject: [ih] FTP design Message-ID: <200208031348.JAA18051@ginger.lcs.mit.edu> > From: "David P. Reed" > Rather than invent a magical "out of band" feature in TCP, which would ^^^ > have multiplied the congestion control complexities, as well as > introducing problems of mixing data and control coding schemes, just > using two connections was simple. Umm, you meant NCP, right? IIRC, TCP FTP was basically a clone of NCP FTP, and we had to make almost no changes at all to make it work. Noel From day at std.com Sat Aug 3 06:57:10 2002 From: day at std.com (John Day) Date: Sat, 3 Aug 2002 09:57:10 -0400 Subject: [ih] A further aside on FTP Message-ID: A side conversation on the file access idea reminded me of an interesting result that came out of it. I had been discussing the idea with various people. Remember the big issue with all of the upper layer protocols was finding the right canonical model for them. The Virtual Terminal for Telnet, the Virtual File System for FTP, etc. The canonical model was definitely not the least common denominator. The big idea was that we avoided nxn transformations of the data by everyone mapping to the canonical form. In any case, Ken Pogran suggested that a byte pointer into the file as in Multics would be an easy way to access a file in a canonical form. It seemed elegant and general and would avoid having to process the whole file to be able to read specific parts of it. So I wrote the protocol as an RFC and Ken implemented it on Multics. (It was latter used as part of a cross network debugger, I understand.) However, we learned that the byte pointer was not quite as easy as we had thought because Tenex's and the FTP virtual file system marked end of record with CRLF and Multics used NL. So our byte pointer was not as straightforward calculation as we had thought. That and some other incidents with Telnet made me realize that most of the data transformations we did were not isomorphic. Hence, the transformations required would have to leave the semantics relative to the application invariant. This sent me back to re-reading Frege as the only mathematician I had ever come across that treated the subject. That was when I realized that the canonical form was the definition of those invariant semantics. Take care, John From braden at ISI.EDU Sun Aug 4 12:14:23 2002 From: braden at ISI.EDU (Bob Braden) Date: Sun, 4 Aug 2002 12:14:23 -0700 (PDT) Subject: [ih] One man's view of Internet history Message-ID: <200208041914.g74JEN925306@boreas.isi.edu> Hi. Last year I gave a talk here at ISI on my very personal view of the first 31 years of Internet history. The slides are at http://www.isi.edu/~braden/myfiles/internet312may01.pdf, .ps.Z Enjoy. Bob Braden From gray at washington.edu Sun Aug 4 13:53:23 2002 From: gray at washington.edu (Terry Gray) Date: Sun, 4 Aug 2002 13:53:23 -0700 (Pacific Daylight Time) Subject: [ih] One man's view of Internet history In-Reply-To: <200208041914.g74JEN925306@boreas.isi.edu> References: <200208041914.g74JEN925306@boreas.isi.edu> Message-ID: Corrected URL: http://www.isi.edu/~braden/myfiles/internet31may01.pdf, .ps.Z -teg On Sun, 4 Aug 2002, Bob Braden wrote: > > Hi. Last year I gave a talk here at ISI on my very personal > view of the first 31 years of Internet history. The slides > are at http://www.isi.edu/~braden/myfiles/internet312may01.pdf, .ps.Z > Enjoy. > > Bob Braden > From braden at ISI.EDU Sun Aug 4 14:15:08 2002 From: braden at ISI.EDU (Bob Braden) Date: Sun, 4 Aug 2002 14:15:08 -0700 (PDT) Subject: [ih] 31 years of Internet history Message-ID: <200208042115.g74LF8T27382@boreas.isi.edu> As 7 people have pointed out to me, the URL should have been: http://www.isi.edu/~braden/myfiles/internet31may01.pdf (I swear I didn't type that 2! Oh well, after 31 years, what is one extra bit?) Bob Braden From dhc2 at dcrocker.net Sun Aug 4 14:18:31 2002 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sun, 04 Aug 2002 14:18:31 -0700 Subject: [ih] One man's view of Internet history In-Reply-To: <200208041914.g74JEN925306@boreas.isi.edu> Message-ID: <5.1.1.2.2.20020804141445.0353aec0@jay.songbird.com> At 12:14 PM 8/4/2002 -0700, Bob Braden wrote: >Hi. Last year I gave a talk here at ISI on my very personal >view of the first 31 years of Internet history. Bob, Thanks! Not sure whether you or others are interested in discussing different perspectives. Your slides on architectural principles are particularly striking, to me, because we seem to have so few references to those principles. I was intrigued by your sense of the IAB Kobe decision on CLNP (OSI). My own sense at the time was that OSI was effectively already dead and that the IAB decision was the final attempt to salvage something from it. (Had there been a real, public process considering alternatives, it is not clear that CLNP should have lost. The preemptive nature of the IAB decision overwhelmed that technical discussion with an IETF identity crisis.) d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From braden at ISI.EDU Sun Aug 4 14:37:30 2002 From: braden at ISI.EDU (Bob Braden) Date: Sun, 4 Aug 2002 14:37:30 -0700 (PDT) Subject: [ih] One man's view of Internet history Message-ID: <200208042137.g74LbUJ04647@boreas.isi.edu> *> My own sense at the time was that OSI was effectively already dead and that *> the IAB decision was the final attempt to salvage something from it. Dave, Hardly!! The IAB decision was based on the belief that OSI was inevitable. We consoled ourselves with the ideas that (1) TP4/CLNP had it close enough to right for the essential architectural assumptions to survive, and (2) in a few ways OSI actually represented a better (later) engineering compromise than what we had (e.g., ES/IS combined ICMP with ARP, which seemed smart.) *> there been a real, public process considering alternatives, it is not clear *> that CLNP should have lost. The preemptive nature of the IAB decision *> overwhelmed that technical discussion with an IETF identity crisis.) *> Well, frankly I like the actual outcome much better, having the locus of technical development in the IETF rather than in ANSI or other government-centered standards bodies. Of course, CLNP would have avoided IPv6, but we probably would have gone through a CLNP2 transition long before this. Bob *> d/ *> *> ---------- *> Dave Crocker *> TribalWise, Inc. *> tel +1.408.246.8253; fax +1.408.850.1850 *> From sbrim at cisco.com Sun Aug 4 14:45:20 2002 From: sbrim at cisco.com (Scott Brim) Date: Sun, 4 Aug 2002 17:45:20 -0400 Subject: [ih] One man's view of Internet history In-Reply-To: <200208042137.g74LbUJ04647@boreas.isi.edu>; from braden@ISI.EDU on Sun, Aug 04, 2002 at 02:37:30PM -0700 References: <200208042137.g74LbUJ04647@boreas.isi.edu> Message-ID: <20020804174520.A2070@localhost.localdomain> On Sun, Aug 04, 2002 02:37:30PM -0700, Bob Braden allegedly wrote: > > *> My own sense at the time was that OSI was effectively already dead and that > *> the IAB decision was the final attempt to salvage something from it. > > Dave, > > Hardly!! The IAB decision was based on the belief that OSI was > inevitable. We consoled ourselves with the ideas that (1) TP4/CLNP had > it close enough to right for the essential architectural assumptions to > survive, and (2) in a few ways OSI actually represented a better > (later) engineering compromise than what we had (e.g., ES/IS combined > ICMP with ARP, which seemed smart.) > > *> there been a real, public process considering alternatives, it is not clear > *> that CLNP should have lost. The preemptive nature of the IAB decision > *> overwhelmed that technical discussion with an IETF identity crisis.) The technical discussion in the IETF was already overwhelmed. The ROAD group reached weak consensus that CLNP was the right thing to do (and I believe this encouraged the IAB), but after that the actual decision in the IETF was 90% based on how well the different approaches were spun. > Well, frankly I like the actual outcome much better, having the locus > of technical development in the IETF rather than in ANSI or other > government-centered standards bodies. Of course, CLNP would have > avoided IPv6, but we probably would have gone through a CLNP2 > transition long before this. > > Bob Me too, and exactly. ...Scott From day at std.com Sun Aug 4 15:36:36 2002 From: day at std.com (John Day) Date: Sun, 4 Aug 2002 18:36:36 -0400 Subject: [ih] One man's view of Internet history In-Reply-To: <200208042137.g74LbUJ04647@boreas.isi.edu> References: <200208042137.g74LbUJ04647@boreas.isi.edu> Message-ID: A couple of quick comments and maybe I will get to a longer consideration later. First, the Illinois group put Unix up on the net in the summer of 75 and by the next spring we had a stripped down Unix running on an LSI-11 with a plasma screen and a touch panel that was also on the Net. Bob is right about how we use to look down our noses at the mainframe systems! ;-) Anything that smacked of mainframes (half duplex, polling, etc) was regarded in much the same way that telephony solutions are regarded today! But Operating Systems were our model for solving problems. One of the things I carried away from the excitement of those early protocol design was the ability of the group to take these dichotomies and find a true synthesis of them. It wasn't just one OR the other or smack the two together as most standards committees do today, but truly finding an abstraction that integrated the two. I am afraid that we have lost that ability. I was surprised to see in the 2nd edition of Radia's book something to the effect of "if you don't like NATs you should have gone with CLNP, it was in the routers and ready to go." Hard to say what not handling that juncture right (whether the answer was CLNP or not) has cost us. Emotions were running pretty high at the time. The Europeans really killed OSI. There is their general view that "if we build it they have to buy it." and designing to a point 15 minutes in the future. They were so intent on the idea that X.25 was the only answer to everything. I can't imagine how we would have supported the web on such a thing. And it continues. Look at Bluetooth from an architecture and protocol design point of view. (Something that even the articles critical of Bluetooth never touch on), it is one of the worse and most short sighted designs I have seen in 20 years. WAP is the same! (Someone gave me a paper on WAP and I looked at for about 10 minutes and said THIS IS VIDEOTEXT!) ;-)) Was Pouzin's CYCLADES group the only ones who knew how to design protocols!? However, there were some good results from the OSI work in terms of understanding some of the theoretical underpinnings of addressing and upper layer architecture. And as you say, ES-IS was a good piece of work as was IS-IS. However, since it was done there it has been pretty much lost, not even the academics have bothered to try to understand what was in there. Although, I am told that much of the OSI management stuff has turned up in the SNMP work. (Another of our mistakes. HEMS had much more potential than either SNMP or CMIP.) Take care, John At 14:37 -0700 8/4/02, Bob Braden wrote: > *> My own sense at the time was that OSI was effectively already >dead and that > *> the IAB decision was the final attempt to salvage something from it. > >Dave, > >Hardly!! The IAB decision was based on the belief that OSI was >inevitable. We consoled ourselves with the ideas that (1) TP4/CLNP had >it close enough to right for the essential architectural assumptions to >survive, and (2) in a few ways OSI actually represented a better >(later) engineering compromise than what we had (e.g., ES/IS combined >ICMP with ARP, which seemed smart.) > > *> there been a real, public process considering alternatives, it >is not clear > *> that CLNP should have lost. The preemptive nature of the IAB decision > *> overwhelmed that technical discussion with an IETF identity crisis.) > *> > >Well, frankly I like the actual outcome much better, having the locus >of technical development in the IETF rather than in ANSI or other >government-centered standards bodies. Of course, CLNP would have >avoided IPv6, but we probably would have gone through a CLNP2 >transition long before this. > >Bob > > > *> d/ > *> > *> ---------- > *> Dave Crocker > *> TribalWise, Inc. > *> tel +1.408.246.8253; fax +1.408.850.1850 > *> From braden at ISI.EDU Sun Aug 4 16:04:26 2002 From: braden at ISI.EDU (Bob Braden) Date: Sun, 4 Aug 2002 16:04:26 -0700 (PDT) Subject: [ih] One man's view of Internet history Message-ID: <200208042304.g74N4Qv26717@boreas.isi.edu> *> OSI management stuff has turned up in the SNMP work. (Another of our *> mistakes. HEMS had much more potential than either SNMP or CMIP.) *> !! I thought I was the only one in the world who believed that HEMS was a better bet. Glad to know I have at least one fellow traveler. But this is diverging from history, I guess. Bob From dhc2 at dcrocker.net Sun Aug 4 16:36:57 2002 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sun, 04 Aug 2002 16:36:57 -0700 Subject: [ih] One man's view of Internet history In-Reply-To: <200208042304.g74N4Qv26717@boreas.isi.edu> Message-ID: <5.1.0.14.2.20020804163158.039ea620@jay.songbird.com> At 04:04 PM 8/4/2002 -0700, Bob Braden wrote: >!! I thought I was the only one in the world who believed that HEMS was >a better bet. Glad to know I have at least one fellow traveler. But >this is diverging from history, I guess. As I recall, there were quite a few people who considered HEMS to be a superior bit of technology. Cleaner, more general, more extensible, ... The problem was that it was not as far along and, of course, SNMP and CMIP had far larger established bases of support. Separate from the political aspects of that disparity, it means that there was more practical experience with the strengths and weakness of HEMS' competitors than with HEMS. d/ ps. At the relevant decision-making bake-off meeting, HEMS author Craig Partridge committed one of our community's better moments of graceful behavior, by pulling HEMS out of the running, as the practical aspects to the situation became clear. ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From touch at ISI.EDU Mon Aug 5 10:28:52 2002 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Aug 2002 10:28:52 -0700 Subject: [ih] One man's view of Internet history References: <200208042304.g74N4Qv26717@boreas.isi.edu> Message-ID: <3D4EB5D4.10509@isi.edu> Hi, all, As a reminder, there are a number of people who subscribe to this list who don't always have sufficient context to follow some of these very interesting threads. I would encourage anyone who is interested to post a brief note explaining any item that might be of future use to this list; these will be collected into a FAQ eventually. Newbies are encouraged to check with Google or their local bookstore in advance of posting a question; that said, there are certainly some items which would benefit from additional information - e.g., protocols no longer in common use, e.g., HEMS, CMIP, or some of the meetings that don't have notes on-line, e.g., the IAB Kobe meeting [e.g., what month, year, etc.] Thanks! Joe From day at std.com Mon Aug 5 11:15:42 2002 From: day at std.com (John Day) Date: Mon, 5 Aug 2002 14:15:42 -0400 Subject: [ih] One man's view of Internet history In-Reply-To: <3D4EB5D4.10509@isi.edu> References: <200208042304.g74N4Qv26717@boreas.isi.edu> <3D4EB5D4.10509@isi.edu> Message-ID: At 10:28 -0700 8/5/02, Joe Touch wrote: >Hi, all, > >As a reminder, there are a number of people who subscribe to this >list who don't always have sufficient context to follow some of >these very interesting threads. > >I would encourage anyone who is interested to post a brief note >explaining any item that might be of future use to this list; these >will be collected into a FAQ eventually. > >Newbies are encouraged to check with Google or their local bookstore >in advance of posting a question; that said, there are certainly >some items which would benefit from additional information - e.g., >protocols no longer in common use, e.g., HEMS, CMIP, or some of the >meetings that don't have notes on-line, e.g., the IAB Kobe meeting >[e.g., what month, year, etc.] Good point! I had thought those were sufficiently recent that it wouldn't be necessary but you are probably right. To wit, a year or so ago I was asked to comment on RFC101 which were minutes of a Network Working Group meeting in 1970. I found that I had to translate them for the journalist. But my favorite cryptic line was: "SRI is porting NLS to an IMLAC." All of you really old guysl keep quiet! Anyone want to guess at the translation? Take care, John From braden at ISI.EDU Mon Aug 5 15:47:14 2002 From: braden at ISI.EDU (Bob Braden) Date: Mon, 5 Aug 2002 22:47:14 GMT Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs Message-ID: <200208052247.WAA25470@gra.isi.edu> *> *> I would encourage anyone who is interested to post a brief note *> explaining any item that might be of future use to this list; these will *> be collected into a FAQ eventually. *> *> Newbies are encouraged to check with Google or their local bookstore in *> advance of posting a question; that said, there are certainly some items *> which would benefit from additional information - e.g., protocols no *> longer in common use, e.g., HEMS, CMIP, or some of the meetings that *> don't have notes on-line, e.g., the IAB Kobe meeting [e.g., what month, *> year, etc.] *> A good place to start is the RFC series. Searching on HEMS and CMIP will provide specs of both (however, I am not sure where the report of the Final Shootout meeting on network management might be available -- maybe in the IETF minutes?). I was surprised to learn (or be reminded) that the minutes of the Kobe meeting are not online, but that does appear to be the case. They are sitting in my iab directory. Since they are of some historic interest, I will take steps to get them online. I must first check with everyone who was present then, to make sure they have no objection. Bob Braden From the.map at alum.mit.edu Mon Aug 5 17:34:52 2002 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Mon, 05 Aug 2002 17:34:52 -0700 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs In-Reply-To: <200208052247.WAA25470@gra.isi.edu> Message-ID: <5.0.2.1.1.20020805164629.01c2da60@mail.lafn.org> At 03:47 PM 8/5/02, Bob Braden wrote: >A good place to start is the RFC series. i beg to differ. the RIGHT place to start, and finish, would have been in the msg that mentioned the several more or less obscure protocols, and 'the kobe meeting' even if it had been findable on-line. unless, of c., the idea of the internet history list is to give students exercise rather than readers useful information.... let me be so bold as to suggest that the issue is reflective of a broader problem in the field. i think of it as the old 'man' page/rfc abstracts problem, where the reader is expected to possess full prior knowledge of all the context the author deems relevant. [and to be scrupulous, i really should point out that 'man' [for 'manual'] pages are the traditionally more-terse-than-concise writeups of unix[tm] commands, since we shouldn't assume everybody reading this is familiar w/ that particular blot on the escutcheon of software documentation ... tho i do think it's fair to assume anybody reading this ought to know what an rfc is, and to have seen enough of them to realize that the abstracts are typically overstuffed w/ unexpanded acronyms; however, just in case....] in the context of a discussion of internet history, i submit we ought to be able to rise above that sort of lazy writing. indeed, to digress just a tad, the 'man' page/rfc abstracts problem itself can be thought of as a reflection of a still broader problem in the field: programmersloppy prose -- which is not only lazy writing but also hazy writing. it seems worth mentioning because a delightful example arose in john day's follow-up to joe touch's msg: being older than john, i naturally wouldn't think of addressing the substance of his question abt what 'sri is porting nls to an imlac' means since he specifically asked that 'really old guys' stay out of it, but i'm confident it doesn't give anything important away to observe that, knowing what both acronyms represent and having used both things referred to by the acronyms by 1972, i really don't think nls would have fit in an imlac. granted, i could be wrong about that, but i don't think i am, so must assume that to whoever wrote the rfc in question 'porting' must have been programmersloppy prose for 'allowing the unique-at-the-time, but probably required and definitely useful, nls interface devices to be supported by an imlac', or something like that, rather than what we'd think of as 'porting' these days and i'm almost certain thought of as porting even when the rfc was written. ok, enough of this. if i don't stop now i'll start grousing about the problems programmersloppy prose -- specifically the inability to distinguish between 'i.e.' and 'e.g.' -- led to in ftp-based netmail [as we called it when we were inventing it], and that'll lead me to grousing about how long it took to get rfc 491 on-line, and that'd lead me to grousing about the fact that rfc 666 is apparently still not on-line, and then i might be tempted to mention who it was who's been promising me it would be put on-line for 5 or more years, and that might seem like i'm getting 'personal', and.... cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] From touch at ISI.EDU Mon Aug 5 17:45:46 2002 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Aug 2002 17:45:46 -0700 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs References: <5.0.2.1.1.20020805164629.01c2da60@mail.lafn.org> Message-ID: <3D4F1C3A.2010501@isi.edu> Mike Padlipsky wrote: > At 03:47 PM 8/5/02, Bob Braden wrote: > >> A good place to start is the RFC series. > > i beg to differ. FWIW, not all three- or four-letter acronyms referred to in these discussions is correctly resolved by searching the RFCs. Sure, pointing to "HEMS, ala the RFCs" is sufficient, but searching the RFCs first for anything is like relying on the first hit on Google. Mike P. brings up a good point. By not providing this sort of mildly redundent context, we're shooting ourselves in the foot, history-wise. Joe From dpreed at reed.com Mon Aug 5 21:19:38 2002 From: dpreed at reed.com (David P. Reed) Date: Tue, 06 Aug 2002 00:19:38 -0400 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs In-Reply-To: <5.0.2.1.1.20020805164629.01c2da60@mail.lafn.org> References: <200208052247.WAA25470@gra.isi.edu> Message-ID: <5.1.1.6.2.20020805235932.03f56b80@mail.reed.com.> Mike - as someone old enough to remember SRI's IMLAC's and NLS's, I think that the problem is not necessarily expanding the acronyms. After all, it matters little that TCP was once called the Transmission Control Protocol, because that tells you no more than the acronym tells you about it. What we are really needing in Internet history is the reconstruction of the context in which those terms were defined. This is what is missing from much of the writings that survive. I happen to have preserved a complete copy of the MSPM (i.e. the Multics Systems Programmers Manual), which was not actually what its title claims it to be, since most of the contents were conceptual design documents, rather than documents about what actually got built (as you know, since much of the excellent prose therein is yours). Without the knowledge of its role, one might actually assume that all of the documents therein represent actual implementations. But that historical context is really only extant in the memories of a few folks 50 years young like myself, or older. It's too bad, because someday our memories will fail, without backup. I think it is just fine to capture some of this context, at least for the Internet, in any form whatsoever, acronym-filled though it may be. Especially the "whys" and "whens" that led to the "whats" - much of which is far more interesting than what actually got put into the RFCs and so forth. If the 666 problem is merely a matter of scanning a paper document, I'd be happy to volunteer to put it in Google-space. There's a whole pile of interesting stuff that I still lug around from those early Internet days waiting for me to sort through it in my dotage - probably much of it is duplicative, but most of it was not in the RFC series. For example, I believe I did the first TCP/IP header compression, which is documented in an MIT LCS RFC that apparently came into play in some intellectual property discussion a few years ago. And there is Steve Kent's design for end-to-end encryption in TCP that never found its way into the official RFC stream as I recall, for political reasons. Lots of other stuff. From the.map at alum.mit.edu Tue Aug 6 00:48:23 2002 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Tue, 06 Aug 2002 00:48:23 -0700 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs In-Reply-To: <5.1.1.6.2.20020805235932.03f56b80@mail.reed.com.> References: <5.0.2.1.1.20020805164629.01c2da60@mail.lafn.org> <200208052247.WAA25470@gra.isi.edu> Message-ID: <5.0.2.1.1.20020805234206.01c2eb80@mail.lafn.org> At 09:19 PM 8/5/02, David P. Reed wrote: >What we are really needing in Internet history is the reconstruction of >the context in which those terms were defined. > >This is what is missing from much of the writings that survive. of course. that's why i was grousing about >the old 'man' page/rfc abstracts problem, where the reader is expected to possess full prior >knowledge of all the context the author deems relevant. right after grousing about the msgs that didn't say what clnp, hems, etc. were and when the kobe mtg was -- and went on to grouse about the apparent abuse of the notion of 'porting' w/r/t nls and imlacs. lazy/hazy writing doesn't pay enough [if any] attention to context. so i'd like to think we're in violent agreement so far, give or take some possible slight misunderstandings of my position on yr part. [e.g., b/t/w, remember/realize, it was john day who was asking people to worry about what nls and imlac -- and, to be scrupulous, i'd add sri, altho i guess that one still exists, sorta, and perhaps can be taken as given -- were, not i.] however, i suggest that sensitizing writers to expand acronyms in order not to assume readers know all the context they [the writers] do contributes to furnishing the readers w/ more of the desired-by-both-of-us context, at least to the extent of defining terms that are part of the context and wh/ should be defined regardless just on that ground, and w/ any luck at all to the extent that [if only by psychic osmosis] it should/can also sensitize the writers to the general problem of paying attention to context above and beyond that wh/ is furnished by doing the right thing w/r/t acronyms. which is to say that i'm not in agreement w/ your >I think it is just fine to capture some of this context, at least for the Internet, in any form >whatsoever, acronym-filled though it may be. assertion, because i think that lazy/hazy writing doesn't furnish useful context, by its very nature. and because i hear echoes in it [where it = the 'any form whatsoever' point] of the repugnant 'a bad protocol is better than no protocol at all' notion wh/ helped lumber the world w/ x.25.... not that i think fear of my righteous literary indignation is going to inhibit anybody from contributing to the list, but just in case i suppose i should promise i won't pick on future examples of lazy/hazy writing gratuitously [i.e., i'll only pick on it if it really bugs me]; i just had a weak moment earlier, triggered by annoyance that if only i knew when 'the kobe meeting' was i might have more ammunition for an argument i've been having about just when it was that 'we' won the protocol wars, since clearly it was after said meeting unless bob braden's middlemiddleaged memory [mmam] is in even worse shape than my own mmam, wh/ is quite unlikely, given that i don't even recall whether it was he or somebody else who was claiming that 'osi' was still an active threat at the time. but i'm trying not to allow mslf to get sucked into an active role on the histlist, in order to protect what little is left of my wrists, fingers, and shoulders, so i'll let it go at that. well, at that, plus a quick comment that the rfc 666 grousing was merely a free-associational jab at the [presumed] conscience of one of the histlist 'members', not an appeal for somebody to scan it. [altho if you have a copy, AND have access to the 'official' posting channels for elderly rfc's, perhaps we should talk off-list, since i've already received >Actually, we are holding off on 666 just to aggregate you. from the miscreant in question [whom i'm far too polite to 'name and shame' publically ... yet], and of course replied >'we'? you mean it's not just you aggravating me, or was that meant to be >the editorial [or perhaps the multiple-personality-disordered] 'we'? so maybe i _could_ use your help....] cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] From craig at aland.bbn.com Tue Aug 6 06:50:22 2002 From: craig at aland.bbn.com (Craig Partridge) Date: Tue, 06 Aug 2002 09:50:22 -0400 Subject: [ih] One man's view of Internet history In-Reply-To: Your message of "Sun, 04 Aug 2002 16:36:57 PDT." <5.1.0.14.2.20020804163158.039ea620@jay.songbird.com> Message-ID: <200208061350.g76DoMtk072442@aland.bbn.com> In message <5.1.0.14.2.20020804163158.039ea620 at jay.songbird.com>, Dave Crocker writes: >The problem was that it was not as far along and, of course, SNMP and CMIP >had far larger established bases of support. Separate from the political >aspects of that disparity, it means that there was more practical >experience with the strengths and weakness of HEMS' competitors than with HEMS Hi Dave: I'd disagree slightly. It was clear that both had far larger bases of support. And SNMP (err, SGMP) had *far far* more operational experience. We had only a single implementation of HEMS at the time of the decision (and in a host, not a router) while SGMP was already in management stations and routers. However, CMIP was not in better shape than HEMS (there wore more implementations but they were incomplete toys -- the CMIP spec was still fragmentary at the time). Craig From craig at aland.bbn.com Tue Aug 6 07:52:27 2002 From: craig at aland.bbn.com (Craig Partridge) Date: Tue, 06 Aug 2002 10:52:27 -0400 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs In-Reply-To: Your message of "Tue, 06 Aug 2002 00:19:38 EDT." <5.1.1.6.2.20020805235932.03f56b80@mail.reed.com.> Message-ID: <200208061452.g76EqRtk073288@aland.bbn.com> In message <5.1.1.6.2.20020805235932.03f56b80 at mail.reed.com.>, "David P. Reed" writes: >If the 666 problem is merely a matter of scanning a paper document, I'd be >happy to volunteer to put it in Google-space. There's a whole pile of >interesting stuff that I still lug around from those early Internet days >waiting for me to sort through it in my dotage - probably much of it is >duplicative, but most of it was not in the RFC series. For example, I >believe I did the first TCP/IP header compression, which is documented in >an MIT LCS RFC that apparently came into play in some intellectual property >discussion a few years ago. And there is Steve Kent's design for >end-to-end encryption in TCP that never found its way into the official RFC >stream as I recall, for political reasons. Lots of other stuff. Dave: What I strongly urge you to do is either donate or will these items to a good archive. I know the Computer Museum welcomes this kind of stuff. Other archives may too. Worth preserving the paper, as the bits have likely rotted away (and will again). Craig From touch at ISI.EDU Tue Aug 6 08:49:31 2002 From: touch at ISI.EDU (Joe Touch) Date: Tue, 06 Aug 2002 08:49:31 -0700 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs References: Message-ID: <3D4FF00B.7020309@isi.edu> Lloyd Wood wrote: > On Tue, 6 Aug 2002, Craig Partridge wrote: >>Dave: >> >>What I strongly urge you to do is either donate or will these items to a >>good archive. I know the Computer Museum welcomes this kind of stuff. >>Other archives may too. Worth preserving the paper, as the bits have >>likely rotted away (and will again). > > ...in addition to scanning/OCRing it and sticking it on a webpage > that is announced on a web-archived list that can be spidered. E.g., this list :-) Again, as we get relevant links and answers, we'll be creating a FAQ hosted at postel.org Joe From faber at ISI.EDU Tue Aug 6 09:48:42 2002 From: faber at ISI.EDU (Ted Faber) Date: Tue, 6 Aug 2002 09:48:42 -0700 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs In-Reply-To: <3D4F1C3A.2010501@isi.edu> References: <5.0.2.1.1.20020805164629.01c2da60@mail.lafn.org> <3D4F1C3A.2010501@isi.edu> Message-ID: <20020806164842.GA79629@pun.isi.edu> On Mon, Aug 05, 2002 at 05:45:46PM -0700, Joe Touch wrote: > Sure, pointing > to "HEMS, ala the RFCs" is sufficient, but searching the RFCs first for > anything is like relying on the first hit on Google. If you're trying to be disparaging about searching the RFCs first, you may want a different comparison. Google's first hit is often good for me. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From dhc2 at dcrocker.net Tue Aug 6 09:51:13 2002 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 06 Aug 2002 09:51:13 -0700 Subject: [ih] One man's view of Internet history In-Reply-To: <200208061350.g76DoMtk072442@aland.bbn.com> References: Message-ID: <5.1.1.2.2.20020806094703.01b77188@jay.songbird.com> At 09:50 AM 8/6/2002 -0400, Craig Partridge wrote: >However, CMIP was not in better shape than HEMS (there wore more >implementations >but they were incomplete toys -- the CMIP spec was still fragmentary at the >time). wow. I DID say that the CMIP folks had more "practical" experience, didn't I? kind or amazing to see their spin doctoring reach across a decade and have that effect. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From dpreed at reed.com Wed Aug 7 06:39:01 2002 From: dpreed at reed.com (David P. Reed) Date: Wed, 07 Aug 2002 09:39:01 -0400 Subject: [ih] Re: internet-history digest, Vol 1 #45 - 11 msgs In-Reply-To: <200208061452.g76EqRtk073288@aland.bbn.com> References: Message-ID: <5.1.1.6.2.20020807093306.03df6c50@mail.reed.com.> At 10:52 AM 8/6/2002 -0400, Craig Partridge wrote: >In message <5.1.1.6.2.20020805235932.03f56b80 at mail.reed.com.>, "David P. >Reed" >writes: > > >If the 666 problem is merely a matter of scanning a paper document, I'd be > >happy to volunteer to put it in Google-space. There's a whole pile of > >interesting stuff that I still lug around from those early Internet days > >waiting for me to sort through it in my dotage - probably much of it is > >duplicative, but most of it was not in the RFC series. For example, I > >believe I did the first TCP/IP header compression, which is documented in > >an MIT LCS RFC that apparently came into play in some intellectual property > >discussion a few years ago. And there is Steve Kent's design for > >end-to-end encryption in TCP that never found its way into the official RFC > >stream as I recall, for political reasons. Lots of other stuff. > >Dave: > >What I strongly urge you to do is either donate or will these items to a >good archive. I know the Computer Museum welcomes this kind of stuff. >Other archives may too. Worth preserving the paper, as the bits have >likely rotted away (and will again). > >Craig I certainly will get around to doing exactly this. (I know about roads paved with good intentions, though). But the fact is that like most people, I need to do the massive sorting of personal stuff from public stuff, and the IPR of others from that which I have the right to donate. In the current economy I'm too busy trying to generate cash flow to feel good about spending this time. From jtk at depaul.edu Mon Aug 26 17:11:39 2002 From: jtk at depaul.edu (John Kristoff) Date: Mon, 26 Aug 2002 19:11:39 -0500 Subject: [ih] ConneXions online Message-ID: <20020826191139.7a1ceb29.jtk@depaul.edu> After my inquiry last year about getting at some of the Ole's ConneXions, he and I started working on getting them into bits. This is work in progress and very slow I'm afraid. You'll welcome to take a look at the following five issues we currently have scanned. Please note, these links are probably going to go away at some point when we figure out a more long-term location. Further, these first few were tests and may be re-scanned later. Thanks go to an undergrad intern working with me this year named Robert Vance who did all the hard work. When we get better gear and more hard copies from Ole we'll be doing more and I'll post future links here. http://condor.depaul.edu/~jkristof/tmp/cnx-1987-05-vol1-1.pdf http://condor.depaul.edu/~jkristof/tmp/cnx-1994-09-vol8-9.pdf http://condor.depaul.edu/~jkristof/tmp/cnx-1995-09-vol9-9.pdf http://condor.depaul.edu/~jkristof/tmp/cnx-1996-06-vol10-6.pdf http://condor.depaul.edu/~jkristof/tmp/cnx-1996-07-vol10-7.pdf John