[HECnet] DECnet session control specification

[Paul Koning]

On Wed, 6 Jan 2010 11:50:05 -0500, you wrote:

"Reserved" means "send zero, ignore on receipt".   It most definitely
does NOT mean "check on receive that this is zero", that's a silly
mistake all too often make in protocol design.   This too is for
mixed
version handling.   If a new flag can safely be ignored by an older
system, then the newer system can simply send that flag in what used
to
be a reserved field, and the right thing happens.

Sure, but I'm not trying to implement something nor to make different
DECnet
versions cooperate. I'm just studying the actual content of some
packets and
have noticed some discrepancies between the standard specifications
and
the
actual data on wire, sent from a VMS V7.2 box to another V7.2 system.
:-)

Finally, proxy was originally a VMS specific enhancement and was
adopted
in some other implementations (I know DECnet/E picked it up, at
least
in
a semi-compatible form).   I'm not sure that it was ever specified in
an
architecture spec.

See above. What I'm looking at is the data exchange between two VMS
boxes,
both at V7.2, so it's not strange to see something about proxies.

Sure.   Actually, proxies did get implemented in a number of places, so
you might see it even cross-platform.

Speaking about specifications, I was thinking that DEC was quite
strict
about this and I was hoping that somewhere there was at least an
update
if
not an entire new specification, or that someone would know who to ask
for.

DEC was fairly strict, indeed.   Sometimes things did get implemented
that weren't well documented.   Also, some sections of DECnet were much
more platform-dependent than others, by design.   Session Control is an
example, and the old network terminal protocols even more so.   By
contrast, things like NSP and, especially, the routing layer were much
more rigidly controlled.

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.

Maybe some former DEC person has copies of these documents tucked away
somewhere.   If so, one might hope that those could be found, in which
case they can be put online.   (Permission was already given to do that
-- permission is NOT the issue in this case.)

BTW, all the differences I've found are in the session control
protocol
and
the one about proxies is just one of them: another is in the contents
of the
format 2 "destination end user name".

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. 

	paul