@dexter When I was a student sysadmin at St Olaf college, Craig Rice, the senior admin dug out the v6 and v7 tapes and had us take a stab at extracting them, pointing me at Mike Haertel (an Olaf graduate) for help. That was, uh, 1993?

Ahah! I found my notes from talk(1)ing with him!
-----v6----
Greetings from the distant past...
So, you've gotten interested in those old tapes, eh?
You're gonna love this...
the v6 tape is 12100 512-byte blocks.
The first 100 blocks are a "tp" format archive.
Yeah, tp. Dig up the old v6 manuals. :-)
The remaining 12000 blocks are evenly split into 3 4000 block
file system images, the first being root, the second /usr/source,
and the third /usr/docs.
(They had different names in those days.)
So, to read those tapes, you're going to have to understand the v7
(I mean v6) file system format. The stuff in the tp archive at
the beginning doesn't relly matter--it is a boot block, and then
a few programs meant to be booted by the boot block. Its main
purpose is to extract the rest of the tape.
Anyway, I went through all this a few years ago. It turned out
to be remarkably simple to write a simple program to read the file
system image, but I no longer have it.

----v7----
Now, about the v7 tape. The format of that tape is as follows:
There are ... 5 files consisting of 512 byte records,
and 2 files consisting of 10240 byte records.
The first 5 files are basically boot stuff again.
The second or third is just a list of the tape contents,
the others are standalone "cat", standalone "mkfs", and standalone "restor",
and the boot block itself.
Then, the last two files are v7 dumps of root and usr.
I have a program I wrote to extract those.
And I still have the sources for that one. So I'll just email it to you.

@mcc It doesn't come through in the RFC, but afaict it's more like "Hangul is too harmonic for our feeble algorithms to handle" Without reasonably interoperable "does <this> equal <that>?" algorithms, IDNA would be unreliable...

To quote selectively from https://www.alvestrand.no/pipermail/idna-update/2008-February/001117.html

"<...>the fact that Hangul is designed so well structured on so many levels (feature, phoneme, syllable) is actually the very reason for why there are so many (fundamentally, not only superficially) different proposals for encodings, [...]. Encoding designers all saw the beauty, but the differed on which level to consider most important. All the other, not-so-well-thought-through scripts give the encoders much less options to work (and mess) with."