Thanks, Terri, that is very kind of you to offer this.
What a finger client will accept and produce has always been highly 
installation dependent, the only consistency between all of them being 
that the local folks thought theirs was the best, the highest complement 
being when one finger adopted another finger's feature.
Tops-20 Finger will accept the following:
      /CPU-IDLE       /DETACHED       /DIAL-IN       /ETHERNET    
    /FULL-USER-NAME    /HELP /INTERNET
      /JOBNAME:       /LOCAL          /LOGIN /NETWORK     
    /NO-DETACHED       /NO-OPERATOR   /NO-PLAN
      /OPERATOR       /PTY            /REAL-LOCATIONS   /TERSE    
    /TTY-IDLE          /TTY:          /TYPE:
      /VERBOSE        /WHOIS
As can be seen, it is almost, but not quite entirely DECnet innocent, 
which is not surprising as this is Standford's finger. It's an 
accumulation of many years of separate authors and separate styles and 
hacks that is kind of crying out for a substantial if not complete 
rewrite.  I don't believe I will have time for that for another two 
years.  For now, I'm just trying to get it to work on DECnet without too 
many sparks flying out.
Columbia's finger did do a better job, but the underlying implementation 
was another can of worms.  Besides, those sources are lost.
/COMMENT sounds interesting, but as I said, I'm still draining the 
swamp, as it were and have not gotten past the alligators.
 
------------------------------------------------------------------------
 On 9/16/24 10:29 PM, Terri Kennedy wrote:
 
------------------------------------------------------------------------
 On 2024-09-16 22:05, Thomas DeBellis wrote:
 As can be seen, the Tops-20 finger client has been modified to send 
 the name of the local user and optional data identifying the finger 
 client.  Probably I'll change that to the finger version.  The RFC 
 for TCP/IP finger is (naturally) silent on what you can send over 
 DECnet, so this doesn't break anything. So, I can finger myself on 
 MIM:: just fine, viz: 
   DECnet uses the same sorts of qualifiers as the TCP/IP version.
   I had added a "/IAM=" qualifier to both VMS and RSTS/E Finger, but  
 it is too easily abused in the modern age, particularly where not all 
 nodes are under common management. The original intent was to have the 
 server display "The user has the following unread mail messages from 
 you" with a number, date/time, and subject.
   I will be removing it from both VMS and RSTS/E Finger (it will no 
 longer send /IAM and will silently ignore any incoming /IAM).
  If you have a finger client that can do DECnet
connections on another 
 platform (I'm thinking VMS or maybe RSTS) and can try it, let me know 
 how you make out.  Be aware that I did just hack this together in two 
 and a half days, so I make no claims to any sort of stability.  I'm 
 just trying to trouble shoot at this point. 
   As soon as I get on HECnet, I'll
be glad to do any interoperability 
 testing you want (and both the VAX and RSTS/E systems will have guest 
 accounts, so you'll be able to log in and test for yourself).
   The currently implemented qualifiers in VMS Finger are:
   /ALL       /BATCH     /BYPASS    /CPUTIME   /FULL      /HELP   
 /IDLETIME             /IMAGENAME /INTERACTIVE          /LOCATION   
 /LOGINTIME /MESSAGE   /NETWORK   /PERSONALNAME         /PID 
 /PROCESSNAME          /SIZE      /SORT      /STATE /SUBPROCESS  
 /SWAPPED   /SYSTEM    /TERMINAL /TTTYPE    /USERNAME
   RSTS/E Finger ignores the ones that aren't relevant to that platform 
 (or aren't implemented).
   I propose we add a "/COMMENT=quoted-string" qualifier. 
 Implementations that don't support it will either complain or silently 
 ignore it. Implementations that support it may choose to log that info 
 (and anything else they care to) in an implementation-specific manner. 
 I further suggest that the comment have a formal (if undocumented 8-) 
 syntax, for example:
 /COMMENT="NODE:nodename,USER:username,VERS:finger-version"
 This will let humans (and possibly programs) parse that info with 
 relative ease.
   What do people think about that?
 _______________________________________________
 HECnet mailing list -- hecnet(a)lists.dfupdate.se
 To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se