Proposal for modifying linking
Proposal to improve the user interface for multi-user linking on Tenex.
Victor, K., "Proposal for modifying linking", RFC 576, DOI 10.17487/RFC0576, September 1973, <https://www.rfc-editor.org/info/rfc576>.
@misc{rfc576,
series = {Request for Comments},
number = 576,
howpublished = {RFC 576},
publisher = {RFC Editor},
doi = {10.17487/RFC0576},
url = {https://www.rfc-editor.org/info/rfc576},
author = {K. Victor},
title = {{Proposal for modifying linking}},
pagetotal = 2,
year = 1973,
month = sep,
} RFC text
Network Working Group K. Victor
Request for Comments: 576 September 1973
Proposal for Modifying Linking
We plan to modify the link jsys in TENEX to work in a little bit
better way in terms of the user interface. Conversations with BBN
indicate that they have no complaints with the current
implementation. However, if after we have gained experience with our
new implementation, we will let them know about it and they will
review the new implementation and possibly accept it as part of
standard TENEX.
I would appreciate feedback in the next couple of days so that I can
go ahead and implement this proposal (or a modified proposal or
nothing...). (I estimate that it will only take a couple of hours to
implement!)
(Note that by modifying the jsys, the proposed changes as specified
will be in effect at the user level in the exec.)
The default state for all users will remain as it currently is, i.e.
RECEIVE LINKS.
Now, consider users A, B, and C.
If A and B link to each other they are now holding a conversation.
After establishing a conversation, all members of the conversation
will be placed in the REFUSE LINKS state.
If user C (or any other user) now tries to link to user A (or B), the
bell will ring on users A (or B) and C terminals indicating that A
(or B) is in a REFUSE LINKS state.
If A ignores the bell then C is not admitted to the conversation
and A and B can continue their conversation as if C had never
tried to enter the conversation.
However, if A does a RECEIVE LINKS while the bell is ringing (the
bell rings for approximately 15 seconds), then C will be linked
into the conversation and not to just user A. Thus A and B will
be linked, A and C will be linked, and B and C will be linked,
i.e., a three way conversation. Also, users A, B, and C will be
in the REFUSE LINKS state.
Whenever a user leaves a conversation, his state will be set
automatically to RECEIVE LINKS.
Thus, when user C does a break links the resulting states will be:
A and B will be linked and both will be in REFUSE LINKS
C will be out of the conversation and will be in RECEIVE LINKS
Now, when A or B does a BREAK LINKS there will no longer be a
conversation and both A and B will be in the RECEIVE LINKS state.
To summarize:
After any conversation is established, all members of the
conversation are placed in the REFUSED LINKS state.
When a user links to a terminal or a user, he is in fact linking
into a conversation if one exists or to an individual if no
conversation is taking place.
When a user leaves a conversation, she is placed in the RECEIVE
LINKS state.
Changes to the TLINK jsys will be necessary to implement the above.
No changes are required in the EXEC. In addition to the above
changes, we will add a new jsys that will return the link and advise
status for a passed terminal, i.e., you will be able to tell which
lines are linked to the passed terminal, which lines the passed
terminal is linked to, which line the passed terminal is advising,
and/or which line is advising the passed terminal. This information
will probably be incorporated into the systat printout, the where is
printout, and will probably be used within NLS for shared screen
work.
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Bob German 7/99]
AI ELI5
On this page
§1The Current Problem
Tenex supports linking terminals for multi-user conversations, but the current interface is not ideal. Users can be in a RECEIVE LINKS state (ready to accept incoming links) or a REFUSE LINKS state (rejecting new links). The proposal aims to make conversations feel more natural by allowing existing participants to accept a new member into their conversation while rejecting random interruptions.
When two people are talking, the system should let them accept a third person into the conversation if they want, but not force them to.
§2How the New System Works
All users start in the default RECEIVE LINKS state. When user A and B link to each other, they enter a conversation and both move to REFUSE LINKS state, preventing random interruptions. When user C tries to link, a bell rings on A and B's terminals. If A ignores it, C is rejected and A and B continue. If A presses RECEIVE LINKS while the bell is ringing, C is linked into the entire conversation, and now all three are linked to each other in REFUSE LINKS state. When any user leaves by pressing BREAK LINKS, they return to RECEIVE LINKS state, and if they were the last member of a pair, the other person also returns to RECEIVE LINKS.
Two people talking can accept a third into the conversation with a bell alert and a single command. When someone leaves, they automatically go back to accepting links.
§3System Implementation
The change requires modifications to the TLINK system call to manage the new linking states. No changes are needed to the EXEC program. Additionally, the proposal adds a new system call that returns link and advise status for a terminal, showing which lines are linked to it, which it is linked to, and which lines are advising it. This information would be useful in status display programs and NLS for shared screen work. The proposal requests feedback within a couple of days and estimates only a couple of hours of implementation work.
This is a system-level change that will mostly involve updating one system call. A new command will also let programs check who is linked to whom.