doc: Add RFC documents

1 files changed, 115 insertions, 0 deletions

diff --git a/doc/rfc/rfc576.txt b/doc/rfc/rfc576.txt
new file mode 100644
index 0000000..6f281c3
--- /dev/null
+++ b/doc/rfc/rfc576.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+Victor                                                          [Page 1]
+
+RFC 576              Proposal for modifying linking       September 1973
+
+
+   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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Victor                                                          [Page 2]
+