1 Jun
2023
1 Jun
'23
6:27 p.m.
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 /un/talent. 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(a)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.