BTBureau of Standards

V 8 1974

-i wefi •

\0C>User Procedures Standardization

for Network Access

A. J. Neumann

Systems Development Division

Institute for Computer Sciences and Technology

(J ,^ t

National Bureau of Standards

Washington, D.C. 20234

t.TtoXuvmuxty v\o\e- *yo> " i

Sponsored by

The National Science Foundation

18th and G, Street, N W.

Washington, D.C. 20550

I*'»a,u <*

*

U.S. DEPARTMENT OF COMMERCE, Frederick B. Dent, Secretary

NATIONAL BUREAU OF STANDARDS, Richard W. Roberts, Director

Issued October 1973

National Bureau of Standards Technical Note 799

Nat. Bur. Stand. (U.S.), Tech. Note 799, 43 pages (Oct. 1973)

CODEN: NBTNAE

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402

(Order by SD Catalog No. C13.46:799). Price 70 cents.

FOREWORD

This report is one of a series of publicationsproduced by the Institute for Computer Sciences andTechnology, National Bureau of Standards, under GrantAG- 350 from the National Science Foundation.

This grant supports a broad program of research intothe foundations of computer networking in support ofscientific efforts.

A listing of completed and planned publicationsproduced by the Institute under this grant follows:

1. Primary Issues in User NeedsD. W. FifeChapter 10 in Networks for Research and Education:

Sharing of Computer and Information ResourcesNationwide

MIT Press, Cambridge, Mass.Expected Publication October, 19 7 3

2. Some Technical Considerations for Improved Serviceto Computer Users

T. N. Pyke, Jr.COMPCON, 19 7 3

Seventh Annual IEEE Computer Society InternationalConference

3. Computer Networking Technology - A State-of-the-ArtReview

R. P. Blanc and T. N. Pyke, Jr.COMPUTER MagazineComputer Society of the IEEE

4. Review of Network Management Problems and IssuesA. J. NeumannNBS Technical Note 795

October, 1973

5. Annotated Bibliography of the Literature onResource Sharing Computer Networks

R. P. Blanc, I. W. Cotton, T. N. Pyke, Jr. andS. W. Watkins

NBS Special Publication 384September, 1973

6

.

Network Management SurveyI. W. CottonNBS Technical NoteFall, 19 7 3

iii

7. User Procedures Standardization for NetworkAccess

A. J. NeumannNBS Technical Note 799

October, 1973

8. Review of Computer Networking TechnologyR. P. BlancNBS Technical NoteFall, 1973

9. Microeconomics and the Market for Computer ServicesI. W. CottonSubmitted to Computing Surveys

10. Cost Analyses for Computer CommunicationsR. P. BlancNBS Technical NoteFall, 19 7 3

11. Network User Information SupportA. J. NeumannNBS Technical NoteFall, 1973

12. Quality Service Assurance ExperimentsR. StillmanNBS Technical NoteFall, 1973

13. A Guide to Networking TerminologyA. J. NeumannNBS Technical NoteFall, 19 7 3

1M-. Research Considerations in Computer NetworkingD. W. FifeNBS Technical NoteFall, 1973

IV

CONTENTS

Page

1.0 Introduction 1

2.0 Functional Summary 2

2.1 Initialization of User Access 2

2.2 Establishing a Communications Channel ... 4

2 . 3 User Identification 4

2.4 Authorization and Access 4

2.5 Obtaining Status Information 4

2.6 Computer and System Selection 5

2.7 Completion of Login 5

2.8 Logout 5

2.9 Accounting Data 5

3.0 Message Types and Procedures 6

3.1 Informational Messages 6

3.2 Command Messages 6

3.3 Special Command Signals 6

3.4 Message Sequencing 6

3.5 Degree of Interactivity 8

4.0 Comparison of Systems 8

4.1 Initialization "94.2 Establishment of Data Channel 9

4.3 Initial System Messages 104.4 User Signal 10

4.5 System Signals 10

4.6 Identification 104.7 Authorization and Access 114.8 Resource Selection 114.9 Logon Statistics 11

4.10 Logoff Statistics 114.11 End Message 12

4.12 Sequencing and Format Options 12

4.13 Default Procedures 12

5.0 Standardization of User Procedures 13

5.1 Need for Standardization 13

5.2 Standardization Criteria 145.3 Standardization Possibilities 14

17Conclusions

... 35

6.0

7.0 References

v

FIGURES

Page

1. Network Access Subsystems 3

2. Message Types 7

3. BASIS Protocol Analysis (System A) 19

4. BASIS Protocol (System A) 20

5. GE MK II Protocol Analysis (System B) 21

6. GE MK II Protocol (System B) 22

7. INFONET Protocol Analysis (System C) 2 3

8. INFONET Protocol (System C) 2 4

9. MEDLINE Protocol Analysis (System D) 25

10. MEDLINE Protocol (System D) 26

11. NIC/ARPANET Protocol Analysis (System E) 2 7

12. NIC/ARPANET Protocol (System E) 2 8

13. SPIRES Protocol Analysis (System F) 29

14. SPIRES Protocol (System F) 30

15. Login Sequence Errors (INFONET) 31

16. User Command Data Elements 32

17. System Messages Data Elements (I) 33

18. System Messages Data Elements (II) 34

VI

USER PROCEDURES STANDARDIZATIONFOR NETWORK ACCESS

A. J. Neumann

User access procedures to information systemshave become of crucial importance with the advent ofcomputer networks, which have opened new types ofresources to a broad spectrum of users. This reportsurveys user access protocols of six representativesystems. Functional access requirements are outlined,and implementation of access procedures is analyzedby means of a common methodology.

Qualitative assessment - of standardizationpossibilities identifies standardization candidatessuch as: system and user signals, on-line userentries, system requests, and network wide categoriesof message content.

Key words: Network access procedures; networking;standardization; user protocols.

1. INTRODUCTION

User access procedures to information systems (userprotocols) are concerned with all actions a network userhas to perform to be able to use the facilities offered bythe network. These access procedures have become ofcrucial importance, especially since computer access nolonger is the exclusive province of the computer operatoror programmer. It is now available to many users, tocomputer specialists as well as to members of other pro-fessional groups interested in research and routineoperations

.

Access to computers is enhanced by the development ofnetworks. Remote users, with a relatively inexpensiveterminal, can now have access to a variety of computerresources on a country-wide basis. As computer systems haveproliferated, so have methods of access. The present stateof the art is one of great diversity, so much so that thelarge variety of access methods often makes it difficult forthe user who is looking for simple, uniform, and reliableaccess methods, yet wants to use diverse resources. Ideally,therefore, access should be similar to that used for world-wide telephone networks, where simple, uniform dialingdevices, procedures, and numbering schemes facilitateoperation.

This study is concerned with a description of access(and exit) mechanisms, as the user sees them. Some

conclusions will be then offered as to possible directionsfor standardization, which may help to unify procedures,and aid the user in access to these systems. The immediatetask of this report is to collect data on access mechanismswith a view to providing a basis for further work in plan-ning, developing guidelines, and possible standardizationefforts

.

2. FUNCTIONAL SUMMARY

An access procedure, as seen by the user, consists ofa series of data entries into the system and of observationof data outputs from the system, or reactions by the system.These actions follow each other in a predetermined mannerand continue until the access procedure is completed.

The point of contact for the user is a terminal whichprovides keyboard entry and display capability. Displaymay be in the form of hard copy, or it may be volatile,such as on a cathode ray screen. There are severaldistinct phases of access which depend on both the charac-teristics of communications and computer hardware, and onthe requirements for access control, handling of traffic,accounting and billing, or control of proprietary informa-tion. Figure 1 illustrates a functional breakdown ofsubsystems. It shows user data terminal equipment, communi-cations equipment, communications circuits, and a hostcomputer providing an operating system, user languages andapplication packages. The communications channel mayinclude computers, such as communications computers andinterface message processors. Terminal equipment inaddition to an operator terminal may provide computingcapability.

The various phases of access are: initialization,establishment of a data transfer channel betweencommunications equipments, establishment of a data linkfrom terminal to the host computer, which results incomputer access and the operation of the working program.Included also must be procedures required for reversal ofthe process, including program exit and shutdown of thesource data terminal equipment.

2.1 Initialization of User Access

The process of accessing a computer network startswith the preparation of communications equipment by theoperator. Power for the terminal proper and ancillary

USER

TERMINAL

DTE

DCE

-CCT

DCE

COMMUNICATIONSCOMPUTER

DCE

^CCT

DCE

DTE/HOST COMPUTER

. OPERATING SYSTEM

. WORKING SYSTEMS

. LANGUAGES

CCT = Communications CircuitDCE = Data Communications EquipmentDTE = Data Terminal Equipment

NETWORK ACCESS SUBSYSTEMS

Fig. 1

devices, among them acoustic couplers, are turned on.Where a choice of terminal speeds is available, the properspeed is selected. Similarly, a communications mode (halfduplex, full duplex) and other terminal options must beselected and, in turn, activated.

2.2 Establishing a Communications Channel

Next, a communications circuit is established betweenthe user's terminal equipment and the equipment at the hostcomputer. This mav be done by message switching or circuitswitching systems. User access is usually through a dial-up connection but dedicated access channels are alsoavailable.

In some networks, this process requires several steps:first, a local communications computer is dialed, andlater a remote computer address is entered. This selectsand connects with the desired host computer. Establishingthe communications channel involves the recognition of theterminal characteristics in terms of terminal speed,character set, and communications mode. Though there aresome systems that provide automatic terminal recognition,in many cases the user assists in the process by trans-mitting a terminal identification code. A few communica-tions computers perform user identification and accesscontrol, but this is normally done by the host computer.

2.3 User Identification

User identification, for both accounting and accesscontrol purposes , requires the operator to enter somespecial information. Usually, such entries involve a usernumber, password, project number, personal identificationcode, or similar information. Most of this informationis entered by keyboard action in a character-by-charactermode

.

2.4 Authorization and Access

Based on the information supplied by the user, thesystem validates his access request, and authorizes accessto the system. In cases where invalid passwords and/or usernumbers are detected, user access is terminated.

2.5 Obtaining Status Information

At some time during the access sequence, the user is in-formed of the network status. He may be told of the present

configuration, the latest software version in use, the portnumber, concentrator and remote concentrator numbers. Heis also informed of planned shutdowns or intended systemchanges. In addition the operability of the system isoften indicated by a "greeting message," including date,time, and other accounting details.

2.6 Computer and System Selection

A common task of interest to the user is the selectionof the computer site, if he has a choice of more than one.Further decisions must be made regarding desired computa-tional or information processing programs and processes.For these purposes, the user enters a site address andvarious codes referring to the systems to be accessed.

2 .

7

Completion of Login

After the access sequence is completed, the systemsends a "system signal" to the user. This means that itis ready for use. At this point, the user may access theworking system of his choice and begin operations.

2 .

8

Logout

The reverse procedure takes place upon leaving asystem. After the user indicates his desire to end opera-tions , the system responds by transmitting data aboutterminal time used, computer time used, and date and timeof logoff. Finally, an "end message" informs the user thathe has been duly logged out and that the system is dis-connecting.

Usually the user must inform a hierarchy of systems ofhis desire to terminate a session. These may include theworking system, the host operating system, and thecommunications computer. There are, however, instanceswhere this sequence has been simplified so as to permitlogout by only one user command.

2.9 Accounting Data

At the end of the terminal session, the user receivesusage measurements. They include time measurements andamounts of storage which record used resources. As a rulethis is part of the logoff procedure. These measurementsare reported together with the appropriate user andaccount number, to assist him in managing his own resourcesand results.

3. MESSAGE TYPES AND PROCEDURES

The access procedure thus consists of an exchange ofactions and reactions between the user and the terminal,which represents the total system to the user. Mes-sages exchanged during the access protocol may be of aninformational type or of a command type. Commands fromthe user to the system are called system commands, or usercommands. Messages from the system to the user are calledsystem requests, or system messages. Figure 2 summarizesthe various message types.

3.1 Informational Messages

Informational messages convey required data to theuser, or to the system for purposes of accounting, usage-measurement, or system performance measurement. Typicalmessages of this nature deal with time, date, location,system status, expended resources and system characteris-tics .

3.2 Command Messages

Command messages, on the other hand, require immediateaction, either on the part of the system, or on the part ofthe user. Typical action commands are system requestslike: "LOGIN PLEASE," or "USER NAME" or commands to thesystem such as "OFF" or "QUIT," which are used by the userto terminate operations. Identification data also fallinto this category.

3.3 Special Command Signals

Two kinds of signals merit special mention: the "usersignal" and the "system signal" named by Little andMooers (l). 1 The user signal is entered by the terminal userto denote that his immediate task of data entry is finishedand that he is waiting for system action. Likewise, thesystem signal, which is produced by the computer, tells theuser that processing is completed and that the next stepis up to him. In interactive processing, these signalsare used most frequently, and thus play a special role.

3.4 Message Sequencing

Diversity of system access procedures exists in thevariety of data elements contained in the informationaland command messages. In addition, sequencing of the1 Figures in parentheses indicate the references at the endof this- paper..

1

/"N

^ CO ft^-N CO CO CO

CO rd ^^ rd

p 4-> -Pv_y

ft < ft

J O -• 53 O -•

< -a ~ CD TD —S a) a) "O H CD CD TJCD Mft CD CO bO^ CD

H rd co a) rd CO CD

CO CO «H Oco C O

gw

CO -H Oco £ O

co Bi CD -H ft Eh CD -H ft

W w £ ft Oh CO £ ft ftCD CO >H

< P • CO •

COco

idCD

W ^^ £ ft

g o <d £ •Hp -M CD 3 ^^

Q \w/ CO +-1 a1 ft ft CO

S >1 CO CD CO CD CD

gQ CO >>

CO

ft ^> CO ft

3-Hg o >> Eh 3o 2 -H ft H CO ft &o g o +J H W O CD

o a) T-i rd P ft ft

o > CD ft ex CD

ft •h rd CO 4-> 3 ft +-> *> co

O ft H C CO TJ ft co C cH o o O CD CD CD O O

g co CD TJ ft 3 O g 3 ft ftH P in co cr1 O H c^-H co

EH •H CD CD ft Eh CD O CD

CO T3) -H ft in ft CO ft rd ft

>H >HCO • « • CO •

^\y^^ gg COP 6 ^>v_/ H CD

rd -l-J w Hw C co CD rti ft

s CD O >> < C cu

o < •H CO CO O CO

l-H CO +J CO •H 3E-h CO CO rd O H -P< w H e -p g rd Og CD g ft 6 -HP^ < O +J g ft

O CO ft ft X W O +-»

ft CO H C <D EH ft Xs w CO •H +J CO C CD

H Si p• CO

•H -P

g ftw WEh COCO pCO o

Eh

QEH gPi Eh

pa CO

CO >H

P;

CO

MESSAGE TYPES

Fig. 2

7

various elements involved in the access, i.e. , the accesssequence syntax, must be considered. The latter containsboth system messages and user messages.

3.5 Degree of Interactivity

Depending on their objectives and skills, users' needsdiffer as to their degree of freedom in system access. Anovice user appreciates detailed step-by-step promptingfrom the terminal. It is equally important to him that hebe able to put in his reply on a simple step-by-step basis,while the experienced user may be willing to trade time andcomplexity, requiring a minimum of guidance from the termi-nal. For these reasons , most systems provide severalaccess alternatives at the user's option.

Access prohave been analyin this analysithree data baseand one node ofCA) , GE MK II (

ARPANET (E), anand letter codefeatures. to theanalyses on pag

4. COMPARISON OF SYSTEMS

cedures for a few representative systemszed and results are reported here. Includeds were two commercial time sharing systems

,

oriented information retrieval systems,the ARPANET. The systems were: BASISB), INFONET CO, MEDLINE (D) , NIC/d SPIRES (F). The ordering is alphabetical,s in parentheses are used to refer systemparticular systems, and to the protocoles 19, 21, 23, 2 5, 2 7,. and 29.

The analyses were limited to development of a uniformmethodology of description of data elements, elementsequencing, and of categorization into message classes.

User and system generated messages are considered.Not considered were data element format details. Data werecollected by entering and leaving the systems under test, andby printing out the access protocols on a teletypewriter.These printouts are shown in Figures 4 , 6, 8 , .10 , 12, 14,and 15

.

Each protocol was then analyzed as to message type andsequencing. These analyses, in a uniform format, areshown in Figures 3, 5, 7

99

} n }and 13.

The following conventions have been observed indocumenting the access sequences for the various systems.A serial number denotes the position of each data elementin the access sequence. The sequence is characterized byfour types of messages: system message (SM) , system

request (SR), user message (UM) , and user command (UC).The system signal is denoted by (SS), while the user signalis denoted by (US). Message categories are denoted bycapital letters. Marginal comments are in standard upperand lower case. End of the login sequence is shown by aseries of dashes. Several message elements printed on thesame line have their own sequence numbers. The logoutsequence starts after an appropriate systems signal.

Comparison of user command and system message dataelement categories and data element sequencing are shownin Figures 16, 17, and 18. Numbers in the boxes of thetables refer to the individual analyses, and indicate theordering of the elements.

Results were not correlated with pertinent systemsdocumentation, nor have all possible variants of displayformats and message sequencing options been explored. Theexamples cited are however representative and serve thepurposes at hand. Discussion of access sequence detailsfollows in the next sections.

4.1 Initialization

In this experiment, a typewriter- like terminal withhard copy output was used/ It was connected to_the BellTelephone System through an acoustic coupler. Initializa-tion here involved turning both coupler and terminal powerto "on," and setting of the coupler mode to either "duplex"or "half-duplex. " Other terminals may have different andadditional initialization requirements.

4.2 Establishment of Data Channel

Access to systems was through the Bell System. Insome cases access is via long distance connections (A)

,

while in the case of ARPANET a local communications computer(Terminal Interface Processor, TIP) provides network accessas well as common carrier switching control for remotecomputer access (E). Various means are used to indicate tothe user that communications have been established. Asystem request "PLEASE TYPE THE LETTER D" (D), a systemmessage giving configuration code, time and time zone,

and date, or no reaction at all, are typical cases. In thelatter case operating procedure requires that the userenter a terminal recognition code, which elicits the firstsystem response (E). If , as in the ARPANET, more than onecomputer is involved, a hierarchy of communications pro-tocols is required, i.e. user to TIP, TIP to host and

finally user to host. After receipt of the systems messagefrom the TIP, and selection of the host address, a systemmessage indicating communications status confirms comple-tion of the data link (E)

.

4. 3 Initial System Messages

A variety of system messages indicate that the datalink has been completed, and that terminal to computerconnection has been established. Such messages range froma mere "HELLO" (E), to more complex messages giving .termi-nal identification codes, date and time messages CO, aswell as messages indicating location, date and time CF).Other initial system messages give system and communica-tions status (E), and identification of systems software(E) (A), equipment and port designations CO.

4.4 User Signal

User signals vary from system to system. On theARPANET several different user signals are being used toenter a remote host. Entering of the host address, identi-fication sequence, and working system code require depres-sion of one terminal key, the "line feed" character.Working program exit requires actuation of two keys,"control," and "D. " Other user signals are "carriagereturn," "new line," and "control, S" (F).

4.5 System Signals

Completion of a system action is indicated most oftenby a "carriage return" following a "line feed." In additionoften a "prompt" signal indicates that the system is readyfor user entry. A variety of symbols are used for thispurpose such as: the 'at" character "@" CE), exclamationmark "J" CO, and question mark "?" CF). Other systemsuse words like: "COMMAND" (A) , "USER" CD), or "READY" CB)

.

4.6 Identification

An identification request is sometimes implied bysystem requests like "PLEASE LOGIN" (A) or "LOGON" CO.In other cases identification is required by standardoperating procedure, where the user, upon receiving theinitial message and a prompt signal, enters his identifica-tion data, like user number, password and identificationcode (E). Some systems request identification detailexplicitly with system requests like "PASSWORD," or "USER

10

NUMBER" (B) (C). Password protection is obtained bynon-printing (E) (D) , or by underprinting (A) (B). Otherdetail required are organization codes or account numbers,and personal identification codes (E).

4.7 Authorization and Access

Invalid passwords or user numbers, like format errorsin entry of identification data may lead to repeatedsystem requests for login, or result in the disconnectionof the system. Figure 15 shows several user numbers whichwere unacceptable to the system because of format error,and brought about the subsequent disconnection of thesystem.

4.8 Resource Selection

In the ARPANET, indications of the host address code"L 2," initiates the establishment of a connection betweenthe user and the remote host (E). After receipt of thegreeting sequence and of completion of LOGIN, the selectedprogram is indicated by inserting the proper code.

In the GE MK II system, the system long form versionmay request the programming language and the file to beused. In the sequence shown here, the user selectsfiles and languages after being put into the READYcondition (B).

"4.9 Logon Statistics

Some systems provide a "logon date" except (D) andCB). They also indicate logon or contact time. One systemprovides both: contact time for the first system contactand logon time for the actual system access (A).

4.10 Logoff Statistics

All logoff statistics provide time and resourceusage information in all cases except one (D). Thatsystem apparently is of an experimental nature, andmetered user charges are not used. (B) includes the time zone,

The ARPANET furnishes additional information, includinga job number, user number, account number, as well as a

terminal number (E). Other systems account for SystemResource Units "SRU" used (C) or for Computing ResourceUnits used "CRU" (B).

11

4. 11 End Message

Two of the tested systems conclude with a final systemmessage: "GOOD BYE" (C)"and "END OF SESSION" (F).

4.12 Sequencing and Format Options

Most systems provide several format options. Sequenceformats vary from a completely "interactive mode," whereeach data element is entered separately and evokes a systemrequest for the next data element, to a "terse sequence,"where all data elements are entered sequentially, separatedonly by the proper syntax separator (space or comma). Inthe interactive mode there are variations among thesystems. The system response may be a system signal, orit may also be an explicit request for the next dataelement, as illustrated by one commercial system whichcalls for user number and password as the initial logonstep. In that system, this information may be enteredas

:

(user number ) (comma) (password) (user signal)

and will elicit a request for "project identification." Apermissible variant in that procedure is to follow thesequence of:

(user number ) (comma) (user signal)

This will automatically provide an explicit request for thepassword. When given, the password is then automaticallyobliterated by a dense character field, thus shielding itfrom human view, yet permitting machine recognition. Anexample of an interactive, prompting sequence is shown inFigure 12

.

4.13 Default Procedures

User errors in entering logon data elements aregenerally handled in different ways . In the extreme case

,

an error might disconnect the system and require reestab-lishment of communications and of the login process. Onthe other end, user errors would be interpreted by thesystem and corrective system messages would provide guidanceThe systems examined here operate somewhere between theseextremes

.

Common user errors occur through the omission of spacecharacters where required, through the use of wrong

12

separators (comma instead of space character), or throughthe entry of the wrong sequence of data elements. Usuallythe systems react by printing repeated requests for logonand then by system cutoff, after a specified number ofattempts to enter the system have been made. Figure 15shows reaction of one system to erroneous data entry.After two attempts of entering a wrong user number withsyntax errors (omission of space character, and substitutionof zero character for the alphabetic character 0) and tworequests for LOGON the system disconnected.

The preceding discussion illustrates the variety ofmessage elements and procedure which make up the useraccess sequences for the various systems. Indications arethat technical changes will continue, although functionalrequirements appear to be relatively stable. Possiblestandardization efforts must take the functional needs andthe rapidly changing technology into account.

5. STANDARDIZATION OF USER PROCEDURES

Standardization of user procedures presents manyproblems. For this reason, there must be a compromisebetween ideal requirements and the capabilities ofthose concerned with implementing them. This is parti-cularly true when time, personnel, and financial resourcesare limited. Requirements are based on the user's needs,while implementation of requirements needs to follow a

course that will produce the most desirable features withlimited resources.

There also is the question who should develop thestandards, private industry or government, and the questionof how badly a particular standard needs to be developed.Early standardization in a developing technology mayinhibit progress , while lack of standardization may leadto a proliferation of non- compatible features. In the caseof network access procedures, this may impact adverselyon ease of computer access and use. Standardization effortsmust also be concerned with the costs which might beincurred by the systems, which may want to adopt proposedstandards

.

5.1 Need for Standardization

The need for standardization in network accessprocedures has been recognized by users of timesharingsystems for some time, especially by those who use differentsystems alternately. The need is now being accentuated

13

with the advent of networking capabilities, where datarequirements are increasing for identification, authoriza-tion, accounting, and data protection. At the sametime, network communications computers, more than everbefore, must recognize a great variety of terminals andterminal options, and both terminal facilities and hostcomputers must interact with communications protocols ofgreater complexity to an ever increasing extent.

5.2 Standardization Criteria

Since the standardization process is slow and timeconsuming, standardization objectives must be carefullydetermined. These are some criteria, on the basis of whichgoals may be established: (1) frequency of usage ofitem to be standardized; (2) commonality, and (3) requiredprecision.

Data elements, or message representations frequentlyused by many users would, if standardized, provide easeof use and reduction of user errors. They would alsoenhance the operation of the system. Therefore, systemmessages to users from different systems having the samemeaning should also have identical representations.As an example, the use of a question mark, asterisk, dash,or other graphic symbol as a system signal adds to userconfusion and dissatisfaction, when meanings in the varioussystems differ. Further, in cases where precise userinput for machine recognition is required, format standardswould improve system operations. On the other hand, systemmessages of an informational nature, not requiring immediateuser action, may be in free format, and their design isgoverned by the basic rules of grammar and by readabilityconsiderations

.

Common use of symbols requires uniformity, not onlyfor machine-readable data but for concepts and humanreadable information as well. Categories of access,accounting classifications, and types of malfunctions, forinstance, need to be described and categorized clearly anduniformly if inter-system operation between variousservices is expected in the network environment.

5.3 Standardization Possibilities

Opportunities for standardization of access proceduresexist in the areas of: message content categories, typesof messages, message formats and sequencing, and descrip-tive terminology.

14

5.3.1 Message Content Categories . Standardization ofmessage content is desirable as it relates toclassification schemes which are descriptive ofmessage content, such as data descriptions, filedescriptions or program descriptions. Likewisenetwork statistics and measurements depend on theclassification of system characteristics of equip-ment and of software, just as accounting proceduresdepend on the structure of accounts.

5.3.2 Types of Messages . The first candidates forstandardization of message types would be theuser and the system signals. Their meaningsare unambiguous and precise, they are the onesmost frequently used on all systems. Uniform-ity in the meaning and use of these signalswould help the use of multiple systems. Nextin line would be "on line user entries," i.e.,user commands (system commands) requiringprecise machine interpretation and reaction.Similarly, system requests addressed to theuser require precise reaction by the user andcould be standardized. Also, the standardiza-tion of user entered informational messages isof importance from an overall systems stand-point. Though they do not affect controloperations, uniformity in inter-systems account-ing, access procedures, and statistical datacollection is required. Similarly systemmessages , in coded form require standarddefinitions to be universally understandable.

Some beginning has been made in standardizationof control elements. Little and Mooers (1)have defined twelve universal user controlactions, and have suggested the assignment ofstandard symbols to these actions. Additionalactions will be required for network operations.Standardization at this functional levelappears practical and desirable. There is aninteraction with existing information exchangecodes (ASCII Code) (3) which also provide forcontrol characters. They do not cover allneeded functions , but standardization of addi-tional functions is in progress. Terminalaccess standards development needs to beclosely coordinated with this work.

Standardization of informational data elementsis a more difficult matter. Some beginning in

15

this area has been made, and continuation andcoordination is required. A standard for daterepresentation has been developed (8) and acceptanceof a standard similar to the date-time group inmilitary communications can be envisioned.Other standard designations might be developedfor resource center locations (along the linesof the three character airport codes) forcomputer system configurations, and for soft-ware designations. Uniformity of definitionswould permit meaningful exchange of operatingstatistics and correlation of system performanceparameters. Other data elements that might becandidates for standardization are those per-taining to system characteristics and errortaxonomies

.

5.3.3 Format Standardization . Format standardizationmay occur at several levels. On a higher level,an entry procedure consists of a series ofinterconnected messages. Their sequencing maybe arranged in different ways according to easeof use from the users' viewpoint, or accordingto the ease of processing from the systems'viewpoint. On the level of individual messages,or words, format considerations arise and needconsideration.

5.3.3.1 Message Sequencing . Figures 16, 17, and ]_8

show that , although there is some agreementamong data elements entered into and receivedfrom the systems , there is little uniformityin the sequencing of data elements within theaccess procedures. Just as in internationaltelephone dialing, where a country code isselected first, followed by an area code andsome local digits — which represents a hier-archy of switching facilities -- a generalconceptual ordering of access informationappears feasible. No recommendation or suggestionson how to achieve this can as yet be made, butthe topic of sequencing merits further consider-ation, from the standpoint of both the user andthe system whose software must process thesemessages

.

5-3.3.2 Word Formats . Then there is the issue ofword formats which directly relate to theability of a system to recognize and respondto its inputs. Such details as punctuation

16

marks and space characters which may appeartrivial to the user, often have syntacticmeaning to control software. Though of nointerest to the human reader, their use mustbe precisely specified.

Little and Moers have taken a dim view offormat standardization, stating that "sincedata formats have a potentially infinitevariety, it is futile to consider the standard-ization of formats themselves." CD. Theypropose instead the standardization of datadescriptions, the logical development ofelements of format generation, and finally astandard method of describing external dataformats for entry and display. Nevertheless,it is believed that some format- relatedstandards might conceivably be developed andwould find general acceptance.

5.3.4 Descriptive Terminology . Related to standardi-zation of message types, content, and formats,is the descriptive terminology which is anecessary adjunct to standardization. Termin-ology needs to be unified, especially sincetechnical considerations of network entryprocedures involve such varied fields as dataprocessing, telecommunciations , linguistics,computer sciences, and other engineering andhuman oriented disciplines.

6. CONCLUSIONS

User network access protocols are becoming of increasinjimportance in utilization of emerging computer networks.Standardization is required in some critical areas and willhave beneficial aspects, in terms of user productivity andeconomics of network operations and utilization.

Standardization has been effected for keyboards (6),(7), but extension towards new requirements for user controlof networks need to be added (2). Standards exist for dataelements, such as calendar date ( 8 ) , and states and countiesof the United States (9), (10). Again there is furtherneed for networking oriented effort.

Work is also underway to develop a unified languagefor describing technical concepts, hardware and softwarefunctions, and overall systems performance (M-) (5). While

17

this work is in progress, it needs the support of all thoseengaged in developing systems standards for network access.Additional definitions are needed in the specific area ofaccess protocols and these definitions need to be integratedinto network procedure standards efforts. It is essentialthat a common language be developed not only to simplifyuser operations but in support of training, maintenance,and the interchangeable use of common network resources.

In summary, it is concluded that there is need forstandardization, that there are definable tasks to be under-taken, and that a standardization effort in user accessprotocols would well be worthwhile.

Such an effort must however be quite broad, considerexisting and planned industry activities , economic impacton user and manufacturers, transitional problems, andrelationships to existing and planned standards in relatedareas

.

18

1,2 SM "BATTELLE INTERCOM 4.0"

3 SM DATE

4 SM TIME

5 SR "PLEASE LOGIN"

6 jucj "LOGIN"

7 SR "ENTER USER NAME"

8 jucj USER NAME

9 SM "HBHHHHH"

10 SR "ENTER PASSWORD"

11f

|UC: PASSWORD

12 SM SPACE

13 SM DATE

14 SM LOGIN TIME

System, Version No,

Underprint

15 , 16 SM EQUIPMENT NUMBER/PORT NUMBER

17 SS "COMMAND"

18 jUC "LOGOUT"

19 SM COMPUTE TIME

20 SM PP TIME

21 SM CONNECT TIME

22, 2 3 SM DATE, LOGOFF TIME

BASIS PROTOCOL ANALYSIS (SYSTEM A)

Fig. 3

19

BATTELLE INTERCOM 4.0DATE 05/15/73Tlfl£ 15..39. 15.

PLEASE LOGIf^LOGINENTER USER NAME- S1AN3S013ftssseaasss enter password-

05/15/73 LOGGED IN AT 15.40.18WITH USER- ID ROEQUIP/PORT 77/50

COMMAND- BASIS

BASIS 70

DO YOU DESIRE OPERATING 1 NSTRUCTI ONS\TYPE YES OR NO/NOPLEASE ENTER YOUK LAST NAME. /NEUMANNENTER THE NAME OF DATA BASE TO BE SEARCHED./ N T I S

ENTER YOU* SEARCH ONE TERM AT A TIME.1/ QUITBASIS 70 HAS

ENJOYED SERVING YOU.DO YOU HAVE ANY COMMENTSXYES-NO/NOCDONT FORGET TO #LOGOUT.# BEFORE DISCONNECTING.)GOODBYE

END BASISCOMMAND- LOGOUTCH TIME .203/JP TIME ^.692CONNEC T T I M E HK S . 2 M I N .

B6/lb/73 LOGGED OUT AT 15.42.08.<

BASIS PROTOCOL (SYSTEM A)

Fig. 4

20

1 UC TERMINAL RECOGNITION CODE

2 SR USER NUMBER REQUEST

3,4 UC "USER NUMBER," "PASSWORD"

5 SS "READY"

6 UC "BYE"

7-9 SM COMPUTING RESOURCE UNITS, TERM. CONNECT TIMETHOUSANDS OF CHARACTERS STORED

10-12 SM LOGOFF TIME, TIME ZONE, DATE

GE MK II PROTOCOL ANALYSIS (SYSTEM B)

Fig. 5

21

HU#=aek73105,READY

bye0000.03 CRU 0000.01 TCH

OFF AT 15:30EDT 08/21/73

0000.03 KC

GE MK II PROTOCOL (SYSTEM B)

Fig. 6

22

1 SM Itmli Communications

2 SM SPACE Format Feature

3 SM PORT NUMBER

4 SM CENTER ID

5 SM SPACE Format Feature

6 SM TERMINAL ID

7 SM DATE

8 SM TIME

9 SR "LOGON?"

10 UC SYSTEM CODE

11 SR "USER ID"

12 UC' USER NUMBER

13 SR "PASSWORD"

14 uc! PASSWORD

15 SR "PROJECT CODE"

16 UC'i

PROJECT CODE

17, 18 SM UPDATE NOTICE ANNOUNCEMENT, DATE

19 SS t? t "

20 ucj "OFF"

21, 22 SM USAGE ON DATE AND TIME

23, 24 SM SRU / ELAPSED TIME

25 SM "GOOD BYE.

"

INFONET PROTOCOL ANALYSIS CSYSTEM C)

Fie;. 7

23

PORT: 6 4

CENTER: 8B

TERMINAL 1071 0S/15/73 13:00:43LOGON: GPSUSER-ID: UBS002PAS S WOR D : -PkOJ CODE: 640090 1

ADM999 1 EDI F/L INFORM 5/14/73•OFFUSAGE ON 05/15/73 AT 13:02:10SRlTS:.8 ELAPSED TIME: 00:00:19GOOD BYE.C-

INFONET PROTOCOL (SYSTEM C)

Fig. 8

24

1 SR "PLEASE TYPE THE LETTER D"

2 UC "D"

3 SR "PLEASE LOG IN:"

4 UC USER CODE

5 SR "PASSWORD:"

6, 7 UC PASSWORD Cnon printing), ACCOUNT NUMBER

8 SM INTRODUCTION

9 SM REQUEST FOR FORMAT OPTION

10 SS "USER:"

11 :UC DISCONNECT COMMUNICATIONS

MEDLINE PROTOCOL ANALYSIS CSYSTEM D)

Fig. 9

25

Of.

hitf)

31

aUl

3; oO 2

(- 2 UJUJ *—

i

to COUJ

orUJ

UJ in rt •

_) < X >—

«

CD UJ UJu.

<r DC:*:

_J s—

*

o z<r <r K> a <V nUJ u3 f-I—

i

UJ to UJ

C£ z "D k{- —I 1

UJ _1 ^ UJ

K t—

•

QUJ2a

UJ CO i—

i

z UJ x*—i a X a:_] z E- <rQ <r oUJ X~2L UJ

zCO1—

1

UJ

XUJ —

1

.^- f-T" -JJ—

UJ oU31£

o s V —

I

f-UJ o

Q X a COUJ h»

ao • m

az

££ UJ UJ <Z <zUJ z 2; [->

H _j ,-t 2 >-H <r UJt- i. 5> -£. S) o _1 aUJ _1 CO -J co o Q X.J 2 no 2 m UJ CO o

Z ^ CO £ r-

UJ Q Q —

1

\ o 2X •* U] • • UJ s .-<

t— 2 5- t: 2; -J -1 UJi—

i

•» >—

i

••> <c z U! -*

uj z. 2 5-

a. a o *—

1

21 ~D f—5- o •• o •• 2; o "3

H _j O -J a v a:"£ ^\> UJ U. 2 C^ #

UJ uj o UJ b h-

•

—

<

i—CO 71 3: CO ^ o <c <r ••

<r <c •o <r CO 'O _J'—

a. ."V

uj UJ V) Ul co 1—4 _J z .-v UJ_i -J <C _] <£ x fj a O COa. a. a. 0, a. Lm X o u, 3

QSWEnc/J

I*co

oooEhO(X

wHow

CDH

26

1 SM "HELLO 306"

2 jUC! "@L 2" Logon command, Host address no. 2

3,4 SM "LOGGER R OPEN T OPEN"

5 SM SYSTEM ID.

6 SM FACILITY ID

7 SM OPERATING SYSTEM ID

8 SS "@"

9 , 10 UC; USER NO/ACCOUNT NO

11 SR "IDENT = "

12 'UC IDENTIFICATION CODE

13-16 SM JOB NO/ TT NO/ DATE/ TIME

17 SM STATUS MESSAGE

18 SS "@"

19 luCi ENTER

2 SS "*"

Identification request

21 UC "E L" Execute Logout

22-27 SM JOB NO/USER NO/ACCT NO/TT NO/DATE/TIME

2 8, 29 SM COMPUTE TIME / CONNECT TIME

30 SS "@"

31 IUC "C"

32, 33 SM "T CLOSED R CLOSED"

NIC/ARPANET PROTOCOL ANALYSIS (SYSTEM E)

Fig. 11

27

coCO

CDCSCO(S

COf-

vO

CO XCO HCO _)

co

sOJ

co

CO H1

ss

OO

2 CV) <n53 T3 CO•JO "0 •»

• 1 co a.•^ CO

i

r—

1

o CO 1

tiJ vO T~ 00X! NT 1 mUJ >- O z

o (- a •V

1—

1

ui Ex] 30z 2 ~£ ^0 0J\ o "D • •

O z -<

f£ CO ~i •» •• Q< —• a f—

c0CO S3 U

'-.1

* m >-H•7^ o

z S o O X en I—

<

_JLd M -) o ;'ii h o o0, • CO i—

i

"0 :0

oCO

Zo

^3 Q

•

£3rr

sO !-• • a. < —I z Ul •• QS> 1-1 >—

<

~-!x] H 3 rj

:n z *-»It V) t- f— <r '0

cc w X i (~ -< UJ 3 ~> z a oO ui a. UJ 00 2 'jj a O 3 i—

<

Ul -J_J CO o o ^ CD UJ z •/> a I

J

a ;£ :0 o_J o rj Z a rxi _i >< o a: "DUJ _J o "C H •—

i

t—

•

z o bJ _j (xJ O f-»

r <S> _1 <2> c& X * Gi> (— a>

wsHCO>hCO

oooEhOPL,

EHH<P^

<o

CM

•HP-i

28

1, 2, 3 SM STATION ID, DATE, TIME

4 SR "NAME ?"

5 UM NAME

6 SR "ACCOUNT?"

7 UC ACCOUNT NUMBER

8 SR "KEYWORD?"

9 UC KEYWORD

10 SR "TERMINAL?"

11 UC TERMINAL CODE

12 SR "COMMAND"

13 UC SYSTEM NAME

14 SM WELCOME ETC, NAME

15 SS M_ 9 II

16 UC "LOGOFF"

17 SM COMPUTE TIME

18 SM EDITING TIME

19 SM ELAPSED TIME

20 SM "END OF SESSION"

SPIRES PROTOCOL ANALYSIS (SYSTEM F)

Fig. 13

29

STANFORD 75 0!5/09/73 11:01:39

NAME? NEUMANN

ACCOUNT? 1067

KEYWORD?

TERMINAL? W99

COMMAND ? SPIRES

-WELCOME TO SPiaeS-2, NEUMANN

— v

-? LOGOFF

COMPUTE TIME =3.39 SECONDS

EDITING TIME = O.Ob SECONDS

ELAPSED TIMS = 00:16:47

END OF SESSION

SPIRES PROTOCOL (SYSTEM F)

Fig. 14

30

POrM": 64GEN TEH: BB

TERMINAL 1233 05/15/73 13:04:55LOGON: UBS002LOGON: GPSUSER-ID: UBS 002USER-ID: UBS002GOOD-BYEGOOD BYE.PW

LOGIN SEQUENCE ERRORS CINFONET)

Fig. IB

31

1

1

1 rGO ftw ftft CD OH ft LD CD r- CO CO 6 CDPL, H o| rd OCO 2 ft

. -£

<ftft E< +J CD J\ w en CM o CM o ft CO XIo H H CM J o o wH

Itird

ft o =

HSM Pn CDJ P J- CD c-- CM ft CD XIQ o CO OW P OSEhW g E2 CD CD fto o CM J" CD CD ft +-> X ftft H H H H o CO oS >>o £H nHH X

CD

CO

ft" •H ^S ft CO J- ft

oHft

wW 6 ftCD H

00CD H

CO = =H 2 EhCO < 00 H Pi H P —< H o CD O COft

— rH

O CDO

C X5cy

X) C 3 rd

O o -Po •H CD >,CD H-> C Pi CD

s • rrj O X ftfd bO O •H CD CD

C 2 h H H-> bO (D HO O M-) rd rd ft O•H H \ •H O •H Ph+-> rd u +-> •H CD 6 Ph CD -Prd 3 CD c ft X CD Ph C CX rQ CD •H CO +J rd -H O•H Pn •H R X -P CO O CO O ft O4h CD > 3 H C CD >.H 0) ,£} •H c CD Sh CD CO CD rH II n M-P 6 g XI X rH X XI CO ft CD rd

C rd 3 fi & +-1 rd H X rd bO >^ bO C ft ft CO,CD 2 2 H O c a < pq c Eh rd bO O J olid 5 3 •H CD •H 3 •rHH in P-J P-i CO O 6 O H-> rd ft CD bfl CO Eh

0) CD CD CO o Ph •H CO +-> h H c 2 P ..

k CO CO CO rd CD > o rd O •rH rd|

Ph H o CD0)

CO

DD p D ft < Eh in

CD

CO

HI ft & ft J ' CD CD CDOft

+J

UJ

Po2

USER COMMAND DATA ELEMENTS

Fig. 16

32

SPIRES F00

H

O Ph wh pi;

H

MEDLINE D oo

W2O oP-i

i

SH1-8

HH PQ

pa «CD S

00HCO <<CQ

LO

H

CO•H-PO

T3O&-P

H

H

r-

1

oCM

jj-

0000

g\

CMLO

COL-- H

rHCO S) CO

a)

CO

p1

J" CO CO zt-

• LOCM

xjrd

CU

CMHo

P< rH

COCD CM jg CMH g

#N CM LO CO H r»

r» H H rH o CMLO £ CMrH

C •

O O •

•H CO S oCO P 3 s «H rrj p -P H rH•H fn rd c • H rd

rd 3 Q -P CD O rd c C CD

-P bO CO H CO S s C o bO bO(1) •H =1 ft H •H H rd

O ip, •P e 6 •H -p H -P CO CO

C rd 6 e 3 fc & rd CO

H O -P Q o o CO a1 o a) -P 6 CU

(D o 00 H o o o W PL, H CO CU

-pCO

2T3w

>» >, CCO CO W

SYSTEM MESSAGES DATA ELEMENTS (I)

Fig. 17

33

CO"—

H(XH Pn (N oo

PhCO

< :

a*p<<\ H uo to 00 J-CJ> H H rH HM

: sw

1 s!M

1 J Q! QHIS

iH

iW

! S 00

! O O H oo coPh

s «%

H r^

H1—

1

^S PQ

iwen

CO CO Jd- |

H H HCO << * #>

CQ no J-

Oa

-p

o

rd\o .

a Orti CU 0) C+-> -H e ,qrd rti -H o H;Q •a +-> •r~> HbC

C•H s-P O

CDO

O Jo .

r- en

1—

COH H H

CM CO .H- UO CO 00 oo r-CM CM CM CM CM CM CM CM

—

CO

—CM

H J- CMCM CM CM ED

CO

i H r-1 H|

CM OO P CDrH r

oPi

aH

1

CM CD H 00 o:

CM cH CM CM CM

CD TJ +-> bi CU

-P cu o Mh C 6 CO

3 CO CU Mh •H •H -P• (^ P- fl! o -P -P 'Ho £ rd C ! bl) •H ac H Ol O TJ PL, ED

• o d) o H CU PL,

• o +-> CU

o fl

3# bO

c O rd

in o £ Q) cu !h

rQ 0) -P e q oo CO a Eh rd •H pd PT' 3 rd H T3 -P COj CO

PhPhoCDOJ

SYSTEM MESSAGES DATA ELEMENTS (II)

Fig. 18

34

7. REFERENCES

(1) "Standards for User Procedures and Data Formats inAutomated Information Systems and Networks." Little,J. L. , and Mooers , C. N. , National Bureau of Standards,Proceedings of the Spring Joint Computer Conference

,

1968, pp. 89-94, 4 references.

(2) "Functional Specifications for Typewriter- Like Time-Sharing Terminals." Dolotta, T. A., PrincetonUniversity, Princeton, New Jersey. Computing Surveys

,

Vol. 2, No. 1, March 1970, pp. 5-31, 25 references.

(3) USA Standard Code for Information Interchange,X-3. 4-1968. United States of America StandardsInstitute. (Federal Information Processing StandardPublication 1, November 19 68).

(4) American National Standard Vocabulary for InformationProcessing. X-3. 12-1970. (FIPS PUB 11, December19 70).

(5) American National Dictionary for Information ProcessinjAmerican National Standards Institute, in preparation.

(6) American StandardTypewriter KeyboardsASA X4. 7-1966.

(7) American National StandardAlphanumeric Keyboard Arrangements Accomodatingthe Character Sets of ASCII and ASCOCR.American National Standard X-4. 14-19 71.

(8) Calendar DateFIPS PUB 4

November 1968U.S. Department of CommerceNational Bureau of Standards

(9) States and Outlying Areas of the United StatesFIPS PUB 5-1November 1968U.S. Department of CommerceNational Bureau of Standards

(10) Counties and County Equivalents of the States of theUnited StatesFIPS PUB 6-1June 19 70U. S. Department of CommerceNational Bureau of Standards

35

<< U. S. GOVERNMENT PRINTING OFFICE : 1973—542-650/61

FORM NBS-H4A (1-71)

U.S. DEPT. OF COMM.BIBLIOGRAPHIC DATA

SHEET

1. PUBLICATION OR REPORT NO.

NBS TN-799

2. Gov't AccessionNo.

3. Recipient's Accession No.

4. TITLE AND SUBTITLE

USER PROCEDURES STANDARDIZATION FOR NETWORK ACCESS

5. Publication Date

October 1973

6. Performing Organization Code

7. AUTHOR(S)A. J. Neumann

8. Performing Organization

10. Project/Task/Work Unit No.

640-2415

9. PERFORMING ORGANIZATION NAME AND ADDRESS

NATIONAL BUREAU OF STANDARDSDEPARTMENT OF COMMERCEWASHINGTON, D.C. 20234

11. Contract/Grant No.

12. Sponsoring Organization Name and Address

National Science Foundation1800 G Street, NWWashington, D. C. 20550

13. Type of Report & PeriodCovered

Interim

14. Sponsoring Agency Code

15. SUPPLEMENTARY NOTES

16. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significantbibliography or literature survey, mention it here.)

User access procedures to information systems have become of crucial importancewith the advent of computer networks, which have opened new types of resources toa broad spectrum of users. This report surveys user access protocols of six repre-sentative systems. Functional access requirements are outlined, and implementationof access procedures is analyzed by means of a common methodology.

Qualitative assessment of standardization possibilities identify standardizationcandidates such as: system and user signals, on-line user entries, system requests,and network wide categories of message content.

17. KEY WORDS (Alphabetical order, separated by semicolons)

Network access procedures; networking; standardization; user protocols.

18. AVAILABILITY STATEMENT

[Xj UNLIMITED.

I IFOR OFFICIAL DISTRIBUTION. DO NOT RELEASETO NTIS.

19. SECURITY CLASS(THIS REPORT)

UNCLASSIFIED

20. SECURITY CLASS(THIS PAGE)

UNCLASSIFIED

21. NO. OF PAGES

43

22. Price

70^

USCOMM-DC 66244-P71

User procedures standardization for network access...

Documents

Transcript of User procedures standardization for network access...