Don't get me started about IETF RFP's...

Should you ever wish to truly drive yourself  crazy, I can't recommend Appendix I (Paged File Structures) of RFC959 highly enough.  It is so specific to Tops-20 and only Tops-20 that you can't implement it without looking at previous implementations of both the FTP client and FTP server on Tops-20 and TENEX.

Before I started on the final part of my FTP server rewrite, I had something that out-performed the BBN server by a factor of 15.  That's right, %1,500; blew it right our of the water.  However, the way paged file structures are defined along with a dependency on out of band EOF signaling completely destroyed that paradigm requiring a third buffer and peeking into the stream.  It's just a hack to transfer files with holes in them.  Necessary, but infuriating...

I'm still trying to figure out how to really fix it.  Probably with co-routines, but you have to do polling for the last itty-bitty bit of data, which either increases your CPU usage or decreases your transfer rate.  I mean, they could have used the control connect to signal EOF and then you wouldn't need to do all that peeking and polling.  Gah...

Having said that, I would have to confess that I always seem to find a way to misunderstand the wording of a standard in such a way as to not get it right the first time around.  It may be an untalent.   So I test a lot...

There are also those occasional cases where certain things are assumed and not spelled out.

For example, I don't recall that DAP 5.6 mandates that dates must be in UPPER case, although the examples do show UPPER case.  You may remember that Johnny and I did some trouble-shooting a few years ago (23-Dec-2019) to determine that RSX wanted UPPER case whereas Tops-20 was sending lowercase.  So the fix was to have Tops-20 accommodate RSX's expectations, but one assumes that should have been made explicit, Somewhere...

---

On 5/31/23 8:42 PM, Paul Koning wrote:

In the architecture group there was a clearly recognized principle -- I think it was actually stated -- that "conformance implies interoperability".  In other words, if you do what the spec requires, "it will just work".  One of the reasons Ethernet was so successful is that this principle holds there, as it does for DECnet.  I remember writing the RSTS software DDCMP driver simply by doing what the DDCMP spec calls for, and it worked exactly as specified.  Sure, I had some bugs where I slipped up, but the spec told me what the right answers were.

The IETF does NOT operate that way.  I once, during the development of the iSCSI spec (RFC 3720) tried to argue that some part of the spec needed repair because it wasn't precise enough to ensure that conformance implied interoperability.  At that point the spec editor (Julian Satran of IBM Research) told me point-blank "that is not a goal of the spec".  And sure enough, just like many of its friends, you can conform to the iSCSI spec and yet fail to talk to other implementations.  The notion of "interop labs" and cross-company test run get-togethers is the price you pay for such sloppy specsmanship.
On May 31, 2023, at 8:21 PM, Thomas DeBellis <tommytimesharing@gmail.com> wrote:
It's a shame about the lost specs, particularly if they were adhered to, which appears to largely be the case with DECnet.  For certain Internet protocols, you just have to see what is going over the wire and reverse engineer from that.  Not the end of the world, but not particularly pleasant, either.