The RFC Archive
 The RFC Archive   RFC 576   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 576

Proposal for Modifying Linking

Last modified on Thursday, January 7th, 2010

Permanent link to RFC 576
Search GitHub Wiki for RFC 576
Show other RFCs mentioning RFC 576







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 top


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 top

Proposal for Modifying Linking RFC TOTAL SIZE: 3916 bytes PUBLICATION DATE: Thursday, January 7th, 2010 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 576: The IETF Trust, Thursday, January 7th, 2010
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement