On Thu, 7 Jan 2010 11:46:38 -0500, you wrote: I'm pretty sure there was a Session 1.1 spec. For that matter, there were (of course) Phase V specs. The problem is that none of these seem to have been preserved. The specs we do have are on-line because Matt had the foresight to put them online way back when, and that stuck. Various other specs were published, or were supposed to be published, but that doesn't mean they are online. I suspect there are some paper specs that could be scanned, if someone wanted to do the work. Then there are some cases where the intent was to publish the specs -- Phase V, Phase IV+ (which is where Session 1.1 might show up) -- but I know of no evidence that this intent was ever carried out. For example, I've never seen any trace of the Phase V specs. I'm wondering if someone like Al Kossow from Bitsavers has something yet to be scanned and (re-)published. From time to time his archive has made available very interesting things. Just to cite one, he surfaced the LAT specification (AA-NL26A-TE) which was not available when Christine Caulfield reverse-egineered the LAT protocol to write her latd daemon for Linux. Yet another archive which sometimes may have interesting documents is Manx. Speaking about protocols, one I'd like to read about is LAST (Local Area System Transport), for which nothing appears to be available on the Internet besides an ASCII text handbook with formatting all screwed up and just some high level details of the protocol (that indeed resembles a glorified LAT). By the way, the handbook part number is EK-LADLA-AS-001, and something about DECnet-Plus is at ftp://ftp.radio-msu.net/.1/ftp.cisco.com/pub/rfc/DEC/ The names in format 1 and format 2 destination descriptors are one example of something that was explicitly left as platform dependent. For example, I think in VMS and RSX it is a program name, but in RSTS (DECnet/E) it's something quite different that doesn't tie directly to a program name at all. In my last message I made a mistake and reversed the names: I wrote about the destination, but I meant the source end user name. Sorry. :-P If I'm right with my findings, the format 2 thing sent from OpenVMS V7.2 to another identical system has the GRPCODE and USRCODE fields used as a big four-bytes field containing the EPID of the "calling" process. And this is not present in the V1.0 specification for the "source end user name". :-) Bye, G.