You are restating part of what is in the DECnet Finger specification that Johnny and I put together.

Have a look at it and let me know what you think.  This is what the RSX11 and Tops-20 implementations code against.

It can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for anonymous NFT.

That should be the basis for the discussion as I will be happy to keep it up to date, but I believe it addresses most of what you refer to, below.

  We've gotten pretty far off track here, dealing with combinations
of DECnet and Internet addressing in the same command.

  I propose the following for DECnet Finger (client and server)
implementations:

  1) A Finger client opens a DECnet connection to object 117 on the
     remote node. If the DECnet nodename is unknown, the Finger client
     can optionally use a (designated by implmentation-specific method)
     "smart" DECnet node which may have a more complete node database,
     etc. In the case of failure, report as much useful failure infor-
     mation as possible if the connection cannot be established.

  2) The Finger client sends a series of characters. These charac-
     ters can be:
     a) A username.
     b) Characters to be matched against personal names.
     c) One or more strings beginning with "/" which may
        or may not have meaning to the Finger server on
        the remote node.
     d) An empty string.

  3) The Finger client then sends a CR (or whatever the
     terminator is, I can't be bothered to drop everything
     and look right now).

  4) The Finger server on the remote node evaluates the line
     received and takes action as follows:
     a) Reports information about that username. If it does
        not match any username, fall through to b.
     b) If the Finger server allows partial name lookups like
        this, return a list of username / personal name lines.
        It may enforce a limit on the minimum number of char-
        acters needed to return the list. If a list is not
        returned, report a "No such user" message in an imple-
        mentation-specific manner.
     c) If the string beginning with "/" is known to the Finger
        server as a valid option, treat it accordingly. If not,
        silently ignore that string and move onto any additional
        strings. It is strongly suggested that server implemen-
        tations support a /HELP string to inform the client's
        user what options are available.
     d) Report information on the system itself, which may or
        may not include information on the host, lists of log-
        ged-in users, etc. per the Finger server's configur-
        ation.

  5) The Finger server closes the connection.

  Things like nodename (either @, :: or both) are handled in an
implementation-specific manner by the Finger server. It can de-
cide to return an error message, forward the request to another
host for processing (in which case all of the contents of the
line sent in #2 above should be passed along verbatim), etc.

  Bear in mind I'm going off of 35-year-old-plus memories of how
this is supposed to work.

  Discussion?
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se