RFC 576

Proposal for modifying linking

πŸ“… published September 1973, from ietf

Proposal for Modifying Linking πŸŽ€

okay bestie, let's get into it πŸ’… this is RFC 576, written by K. Victor back in September 1973. It's titled Proposal for Modifying Linking. The original doesn't list a category, and it doesn't say it obsoletes or updates anything, so there's no drama there 🫢


The Big Idea ✨

so K. Victor is planning to tweak the link jsys in TENEX so linking works a little better for users πŸ’– the network folks at BBN had no complaints about the current version. the plan is to try the new one first, then let BBN check it out and maybe accept it as part of standard TENEX 🌸

K. wants feedback within the next couple of days so they can go ahead and build it. they also say it'll only take a couple of hours to implement, which is giving efficient 🧚 (the author adds "or a modified proposal or nothing..." lol, very open-minded πŸ’œ)

Because the change is made in the jsys, the new behavior will show up at the user level in the EXEC.

The Defaults πŸŽ€

the default state for everyone stays the same: RECEIVE LINKS πŸ’– nothing about the basic setup is changing.


Conversations Are a Whole Vibe πŸ’¬

now let's meet the cast: users A, B, and C πŸ‘‘

if A and B link to each other, they're now having a conversation πŸ¦‹

once a conversation starts, every member gets switched to REFUSE LINKS πŸ™ˆ so nobody just barges in.

if user C (or anyone else) tries to link to A (or B), the bell rings on both A's (or B's) terminal and C's terminal, which tells everyone that A (or B) is in REFUSE LINKS πŸ””

  • if A ignores the bell, C doesn't get in. A and B keep chatting like C never even tried πŸ’…
  • if A switches to RECEIVE LINKS while the bell is still ringing (it rings for about 15 seconds), then C gets pulled into the conversation, not just linked to A 😭

that second one is where it gets iconic. A and B are linked, A and C are linked, and B and C are linked too, so it's a three-way conversation 🌈 And A, B, and C all end up in REFUSE LINKS πŸ”₯


Leaving the Chat πŸšͺ

whenever someone leaves a conversation, their state gets set automatically back to RECEIVE LINKS ✨

so when C does a break links:

  • A and B are still linked, and both are in REFUSE LINKS πŸ’œ
  • C is out and back in RECEIVE LINKS 🌸

then if A or B does a BREAK LINKS, the conversation is over, and both A and B go back to RECEIVE LINKS πŸ’€ (they were literally just vibing)


The Quick Recap πŸ“

the summary, no cap:

  • once any conversation is established, everyone in it goes to REFUSED LINKS (that's the spelling in the original, bestie 😭)
  • when someone links to a terminal or a user, they're actually linking into a conversation if one exists, or to an individual if not 🧚
  • when someone leaves a conversation, they go to RECEIVE LINKS πŸ’–

What Changes Under the Hood πŸ”§

the TLINK jsys needs changes to make all of this work πŸ’… but the EXEC doesn't need any changes at all πŸŽ€

there's also a brand new jsys that will return the link and advise status for a passed terminal πŸ¦‹ so you can see:

  • which lines are linked to that terminal
  • which lines that terminal is linked to
  • which line that terminal is advising
  • and/or which line is advising that terminal

this info will probably show up in the systat printout and the where is printout, and probably get used in NLS for shared screen work 🫢 it's giving collaboration energy ✨


[This RFC was put into machine readable form for entry] [into the online RFC archives by Bob German 7/99]

πŸ“¦ where this page comes from