__________________________________________________

Document stats.

Most recent update	20230504
approx. words	46,622

__________________________________________________

SysLink
A Communication Protocol

Contents Of This Document

Administrative Text is not part of the SysLink protocol.

_________________________
Administrative Text
Section
Presentation

Address : jragan.com/syslink.htm#R.20.00

-- . --

I do attest that this protocol is entirely my intellectual property.

I hereby offer this protocol as a gift for public use free and clear of copyright and without reservation, requirement, or encumbrance of any kind so that it may be used, copied, and distributed by everyone for any purpose with the following exclusions and exceptions.

Specificity :
      The gift of this protocol is specific and does not include any other intellectual property. I retain the copyright to all else unless specifically and explicitly stated otherwise. This gift does not in any way involve, include, or refer to AxleBase* or any other intellectual work.

Exclusion :
      The SysLink name as a communication protocol is not included in this release, but the name may be freely used for, with, and in reference to this protocol.

Exclusion :
      This release does not include the right to develop or alter the protocol. ( The developer invites requests and suggestions.)

Exclusion :
      Protocol development will not be bound by this release, so the protocol is subject to change at any time.

John E. Ragan      
1 November 2009
Member, Internet Technical Committee

( The gift is certainly given, but the customary attribution would be appreciated.)

( See the Technology History.)

( Comments: Suggestions and comments should be sent to john in this domain with SysLink as the subject. They will be considered with appreciation.)

( AxleBase*)

_________________________
Administrative Text
Section
Technical Objectives

Address : jragan.com/syslink.htm#R.50.00

-- . --

SysLink is an application-level communication interface protocol. The interface may be between systems, organizations, networks, protocols, etc.

This protocol has these explicit thrusts:
      Universal interface between alien systems.
      Support of unattended systems.
      Ease of comprehension by humans.
      Low cost local implementation.
      A framework for extreme security.
      Project management assistance.

The SysLink protocol sits in the application layer at the top of the network stack. Within that level, it is lower than many other application layer protocols, so it can support them. For example, it can support this protocol stack transmission:
            PHONE BILL/ EDI/ SMTP/ SysLink/ TCP/ IP/ (etc.)

The protocol segregates and encapsulates a specific conceptual area to ease identifying and focusing on an area of development or maintenance in this era of very large and complex systems. To additionally ease development and debugging in this complex profession, it is explicitly designed for human readability as well as for machine use. All commands, controls, and envelope objects can be red (read) and immediately comprehended by a person.

Because it is for machine use, all elements and command strings are precisely specified. The verbosity that makes them legible to people is also intended to give them a high degree of self-validation. Those factors are intended to increase the reliability of systems, assist programmers, and overcome infrastructure noise and disruption.

Verbosity of the envelope is intentional. It minimizes processing logic, and it secures the receipt of a known structure in all cases. The universalization of SysLink will cause its application in many different and unrelated areas, and users will be tempted to drop elements of the protocol that they do not use. That serious error would lose continuing communication and security support in those areas.

Recognized are the many abstraction levels and abstraction paths that must be manifested in the technology of manmade systems. That wonderful body of abstraction is manifested in SysLink by designing SysLink for any software and hardware that is able to use the ASCII character set. The embedded logic, control strings, processing identifiers, etc. are designed to allow alien operating systems, programming languages, application systems, and logical objectives to communicate with each other. With SysLink in our toolbox, communication between a mainframe and a molecular-level computer has become trivial.

The architecture presents a framework that can support extended and unspecified security protocols as well as the legacy protocols such as authentication, encryption, passwords, etc. to allow the use of sophisticated selectable ratchet stops. The entire protocol is publicly manifested because the "bad guys" will discover it in any case, but it is designed to provide both light and extremely strong security (see the "Security Appendix" in the "Advanced Topics").

Effort is made to minimize its size and processing requirement, but application-level communication needs are more complex than are those of lower levels. After considering Man's current computing power, communication infrastructure, and the massive amount of nonsense being carried by the infrastructure, SysLink's footprint is deemed inconsiderable. But for organizations that have minimal programming talent, the protocol allows participation with minimal feature implementation.

Comments and suggestions concerning this protocol are welcome.

_________________________
Administrative Text
Section
A Non-Technical Summary Of Protocol

Address : jragan.com/syslink.htm#R.50.00

-- . --

Except for very small and specialized jobs, our attempts to build smart machines were based on ignorance and they were failures. Instead, we attained great computer power by building machines that obey the commands of software systems. Therefore, those computers do not communicate any more than your telephone communicates; just as people use the telephone to communicate, systems running on computers use the computer to communicate.

Communication between computer systems is a complex task that requires many kinds of hardware, software, and protocols. All of those pieces of the infrastructure do well at their tasks. SysLink is an addition to the communication operation to solve problems that were previously inappropriately or insufficiently addressed.

SysLink is a set of rules that help systems on computers talk to each other. Those rules guide the programmer in building a SysLink system, and tell managers how they must use that SysLink system. Most of the rules are optional to allow programmers and managers to decide whether or not to use them, so even simple systems can use SysLink. But the entire set of rules can be used when communication must be highly controlled and very secure.

SysLink is a system-level protocol. Communicating systems use and control it regardless of what the network and the computer's operating system do. The infrastructure usually does its job well, but it cannot know what a system needs. Just imagine the phone company or government trying to control your conversations.

SysLink rules are designed for guidance of system designers and programmers. Thus, a system can be built to be SysLink-aware. It can even be made discoverable. Any system in the world that uses SysLink can interface with other SysLink systems. Organizations may also build central SysLink servers to insure correct, secure, and standardized use of SysLink by the entire organization.

SysLink has two main features that are
      an envelope
      and a small set of commands.
With a few rules that support them.

The envelope encloses the data between a header and footer that are constructed without regard to the data. That construct allows any kind of data or message to be transported.

The envelope header carries information about the transmission in dedicated slots, most of which are optional. The protocol specifies the information carried by each slot and how it will be stated. The slot architecture increases efficiency and security. It allows the receiver to quickly read, validate, and analyze the header information. (System developers, the slot architecture is not a name-value pair architecture.)

SysLink assists with fault tolerance by offering extremely robust asynchronous communication sessions. At the moment in history when SysLink was released, communication links were stable and quiet, but the SysLink design allows for the possibility that that moment might be brief. At the extreme, even failure of the global internet may pause, without necessarily breaking, a SysLink conversation. That safety is provided at a high level of abstraction to help system designers intuitively use it if they want to.

This point is very simple, but may seem hard to understand at first glance because it involves high-level communication abstractions. As much as possible, SysLink is divorced from all communication transport, including hardware, media, protocols, etc., to allow any communication path to be used. That was done to give flexibility for advances in communication technology, to support advanced system hardening, and to support the most primitive of exchanges. As new technologies have appeared over SysLink's first decade of life, they have been SysLink-compatible.

SysLink can even support a conversation over a route like this:
      Sent over ethernet
      to an inter-planetary transmission
      to a hand-delivered floppy disk
      to the internet
      to a wireless network
      to a hand-delivered DVD.
SysLink is explicitly designed for interactive conversations over even that route, and perhaps far worse.

That may seem trivial until you consider the power that it delivers to a computer system. For example, the AxleBase* database manager could not care less about how a data query is sent to him. Whether it arrives via a data link or email, he can process it and respond because one of his optional interfaces is SysLink.

The command set is a set of commands and controls that the communicating systems can exchange within envelopes. The protocol refers to them in the singular and plural as CCS, which means Command and Control String(s). A few are required, but most are optional.

Although a person can read every CCS, it is a computer system code. The CCS set's purpose is to allow totally unlike, alien, systems to communicate. The CCS encapsulates concepts and actions that are familiar to computer system builders of all languages so they can provide nearly universal communication.

Everything is sent and received in an envelope. For example, the CCS request for communication is
              ** open new syslink session **><
so the transmission will be something like
              envelope header
              ** open new syslink session **><
              envelope footer

Notice the precision and lack of ambiguity in that transmission. Participants know precisely how to construct it, send it, read it, and understand it. Rules tell them how to respond so any kind of system can be programmed to respond automatically. The protocol is large enough for flexibility, but simple enough for systems to use it without human intervention.
The recipient system might elect to reply with
              envelope header
              **authenticate**authenticate**
              envelope footer
to demand that the sender authenticate himself,
or perhaps with
              envelope header
              **syslink session identifier**>pr4Wf1iFfedffdhd7 etc.<
              envelope footer
to start the communication session.

One might ask why SysLink is needed now, since systems have been communicating for decades. The answer is that each of those communications required a custom-made interface, which required programming and(or) people assigned to babysit it. So every communication required a costly interface.

Now, a manager in Zimbabwe can phone a manager in Chicago, to whom he has never spoken, to tell him that his programmers have created a SysLink interface, its address, and which slots to fill in each header. The Chicago company can, on that very day, start routinely and automatically sending EDI phone bills to the Zimbabwe computer, and the comm link on both ends will be entirely unattended.

( AxleBase*)

_________________________
Administrative Text
Section
Language Specification

Address : jragan.com/syslink.htm#R.70.00

-- . --

If your native language is not English, then you may be sensitive to the explicit specification of English within this protocol. Please be aware that this protocol was constructed by one who is aware of the thousands of Man's languages; many are powerful and lovely and offer unique features; many of which you have not heard are spoken by millions; many languages have recently died, forever. Furthermore, the religion of this protocol's creator teaches that our Creator wants us to have many languages, so your native language is worthy of preservation just because our Creator values it.

But SysLink is a technology. Accomplishment and encouragement of inter-system, international, and inter-cultural communication by technical means requires standardization. So for practical reasons related to the world-wide culture and technology, Standard American English, Arabic digits, and ASCII characters are the SysLink standard.

Translation of this document into any language is encouraged. But the specification must not be altered and the literals must be reproduced explicitly and without translation or alteration within the text. In languages that employ greatly differing visual formats, literals may be entirely replaced within the translation by explicit references to the original document, or they may be reproduced photographically, but they may not be expressed in an altered form because they are literals. Please include this language section in your translation.

It might be helpful, and perhaps comforting, to think of the literals in the way that you would consider ancient Egyption cartouches. In that concept, they become coherent symbols that are imbued with complex powers, and the literal symbols within them must be accurately preserved for systems and communication experts.

Please note that the words "foreign" and "alien", as used in this particular document, refer to the many disparate and dissimilar systems around the world. To this writer, even their differentness may not be a bad thing, but their inability to communicate is, for which SysLink was created.

Constructive criticism from you regarding the construction and mechanics of the Language Recognition sub-section of the Universalization section would be sincerely appreciated.

( If your native language is obscure and spoken by few, but you, in your native land, converse daily with your children in it, then on behalf of linguistics scholars who know the value of your effort, thank you for preserving a treasure that our Creator gave to Mankind. May he smile on your labor when you feel alone.)

_________________________
Administrative Text
Section
Release Identification
And Upgrade Proposals

Address: jragan.com/syslink.htm#R.80.00

-- . --

Current Release Number :   180101

Changes Made By The Current Release :

The envelope's slot 9 date specification is altered
to allow other protocols, but with great deference to
the CoreDate protocol.

Implementation Of Proposal(s): none

________________________________________

Proposal 26:   The following is proposed.
          Comments will be considered with appreciation.

Creation of the envelope's slot 22 with expansion
of the protocol's universalization has impacted the
      **reverse connection to port** CCS
so that CCS is being reconsidered.
It may be altered, expanded, or dropped.

________________________________________

Proposal 23:   The following is proposed.
          Comments will be considered with appreciation.

Optional standardized responses to the information
query return CCS when service discovery is used.
See the canonical categorical request in the "query CCS",
and the "Query Response" section of the Protocol
"Implementation Tutorial" appendix.

________________________________________

Proposal 24:   The following is proposed.
          Comments will be considered with appreciation.

Clarification and expansion of Error responses.
Utility expansion is needed while maintaining simplicity.
See new needs in the Error Handling , sub-section of
the Routing section in the Protocol Implementation
"Tutorial" appendix, and the proposed routing error in
the CCS section.

________________________________________

The Release History appendix shows previously published protocol releases.

Definition of Release :
      A release identifies a published change in the protocol.
      It identifies that publication object.
      A release identifier is a six-digit number.
      Release identifiers are sequential.
      They are not necessarily consecutive.
      Release identifiers are derived from dates.
      They usually coincide with the date of publication,
          but are not required to do so.
      Digit quantity is set to support a century of legacy systems.

Version Numbers :
      SysLink does not use version numbers.

__________________________________________________
__________________________________________________



SysLink Protocol Follows



__________________________________________________
__________________________________________________

SysLink
Protocol

Address: jragan.com/syslink.htm#S.00.00

-- . --

The SysLink protocol governs communications at the application level. Levels below that are expected to be governed by their own protocols, and are expected to not impinge upon the SysLink level. The communicating systems will open, employ, manage, and close the SysLink communication session.

SysLink is specifically independent of transport technology including its hardware, media, software, protocols, and types of communication technology. Although originally created and implemented in a computerized electronic environment, and although parts of the protocol are optimized for handling by computer programs, neither the computerized nor the electronic type of communication technology is specified within protocol. (See also the Unusual Or Miscellaneous Technologies section of the "Implementation Tutorial" appendix.)

_________________________
_________________________
Protocol
Section
Transmission

Address: jragan.com/syslink.htm#S.05.00

-- . --

Noun Morphology :
      A SysLink transmission is a SysLink envelope.
      A valid transmission contains nothing outside the envelope.

Verb Dynamics :
      The envelope is handed to lower protocols.
      It is moved between systems by lower protocols.

_________________________
_________________________
Protocol
Section
Session

Address: jragan.com/syslink.htm#S.10.00

-- . --

A SysLink communication session is defined by its character. It consists of multiple transmissions that are exchanged by the session interlocutors. A session includes:
      A transmission that is identifiable as the opening transmission.
      A transmission that is identifiable as the closing transmission.
      And all interceding received transmissions.

SysLink session interlocutors are systems that have recognized each other within protocol and that have agreed to participate in a mutually recognized SysLink session.

The reality and state of a communication session are independent of the state of the infrastructure and may be known only to the interlocutors. The nature and state of the infrastructure may change to any degree in any dimension without altering the session or the session state.

A session may have an identifier that is shared by the interlocutors.

To support very tight security, an acknowledgement of the open request is not required. It is possible for a valid session to transpire with the requestor not receiving a transmission, but that does not change the basic session definition. It is recommended that the opener require a response to at least one transmission to verify the session state before proceeding. Commands are available for that.

A session remains open until it is explicitly closed. Closure can be a unilateral notice or may be negotiated. Closure occurs for an interlocutor when closure notice is either sent or received. Closure renders a session non-existent and undefined.

If the remote interlocutor fails to respond, then the local may unilaterally elect to close the session. The identification of a failure to respond may be a single check or may be negotiated. Closure in any case will be made explicit by a closure transmission regardless of the states of infrastructure and interlocutors.

Closure retransmissions are not required. If a link or segment link requires synchronous connections for transmission, as do socket links, then a valid attempt to transmit the closure will suffice. If a link or segment link uses timeouts, as does TCP/IP, then a valid closure transmission will suffice. A valid syslink-compliant system will transmit required closures regardless of infrastructure state characteristics.

Server timeouts are permitted, but the server must send a closure notice. (note 1)

There is no transmission outside of a session. Opener and closure transmissions are part of a session if the opener was successful.

Relativity :
      Relativistic effects are specifically not addressed.

( Note how the process can cause superfluous closure transmissions that are not within a session and that are not protocol errors. )

_________________________
_________________________
Protocol
Section
Universalization

Address: jragan.com/syslink.htm#S.20.00

-- . --

Protocol
Section
Universalization
Sub-Section
Permitted Characters

Address: jragan.com/syslink.htm#S.20.05

-- . --

Contents of the envelope header and footer are Standard American English, Standard English characters, and Arabic digits that have been subsumed by English.

Where numbers are specified, they are literal Arabic digits with no text.

In those header slots that specifically need them, such as "payload language", "routing", and "activity rubric", punctuation characters and special characters that are visible on the American keyboard may be used.

Formatting characters and control characters outside the payload are not permitted except where specified. The specification includes three unprintable control characters in the envelope.

The entire range of permitted characters is ASCII character code 32 to 126, including those two characters. By definition, therefore, their representation is defined by the American keyboard.

CCS strings are literals. CCS string and character specifications will not be altered or translated and no substitution will be made.

The envelope header and footer will not be altered, abbreviated, or translated.

Unicode :
      The foundation of SysLink security includes absolute character control within processing systems and in expression in the human interface. The allowed set of expressed characters is small, and the protocol explicitly addresses them by their original ASCII code numbers so that transmissions within protocol must use those ASCII codes.
      The security problem that was created by unicode is thereby eliminated. Unicode is not used in the header, footer, and CCS. Each printable character is represented by its original single ASCII code.
      Protocol also requires the ability of a person to visually verify a SysLink transmission, including its compliance with specified character counts, even where communication is totally automated. The elimination of unicode insures that the expressed character count and byte count are identical so that readings by machines and humans are unambiguously comparable.

Protocol
Section
Universalization
Sub-Section
Encryption And Compression

Address: jragan.com/syslink.htm#S.20.30

-- . --

Encryption and compression may be used only in the following manner.

1. Entire Transmission :
      An entire transmission may be encrypted and(or) compressed.

2. Contents :
      Envelope contents may be encrypted and(or) compressed; i.e. everything between the header and the footer.

3. Payload :
      The payload may be encrypted and(or) compressed.; i.e. that which the application system intends to send or communicate, and which is part of, or all of the contents.

Any of those three options may be combined to compound encryption and(or) compression.

An envelope header and(or) footer will be compressed or encrypted only if that compression or encryption is a result of one of the above specifications.

A CCS will be compressed or encrypted only if that compression or encryption is a result of one of the above specifications.

Protocol
Section
Universalization
Sub-Section
Identifiers In SysLink

Address: jragan.com/syslink.htm#S.20.30

-- . --

This pertains to all identifiers specified in this protocol.
They may be referred to herein as identifier or as ID.

Identifier strings are case-sensitive literals.
An identifier string will not exceed sixty characters.
The string space is:
      Standard American English letters.
      Upper and lower case.
      Arabic digits.
That yields a string space of 62 characters.
Each character in the ID string will be selected from the entire string space.

Because the string is a literal that delivers a universally identical read by any and all kinds of systems that also must match human reads, and because it must transcend technologies, unicode is not allowed. The string delivers identical character counts at the machine level and the printed page level.

An ID is generated to be universally unique within its identification domain by randomly selecting each character of the ID from the entire available string space. That uniqueness probability may be relaxed to:
      The limitations of the software tools.
      The limitations of the application.
      The string length limit.

ID collision is not an error. The ID size is expected to suffice for the support of universal communication, but its random generation will produce some duplication. However, duplication due to inadequate generation control is an error.

An identifier will not incorporate or be based upon :
      An existing identifier of any kind.
      Identifiable information of any kind.
Communication will cease without notice for violation of this requirement by a dishonest software vendor.

Protocol
Section
Universalization
Sub-Section
Language Recognition

Address: jragan.com/syslink.htm#S.20.50

-- . --

To encourage preservation of Man's rich linguistic heritage and to please our Creator, who likes the differences that he created, the envelope header has an optional language identifier slot.
      A value will identify the language of the enclosed payload.

A value will be
      the commonly recognized name ( * ),
      in Standard American English,
      entirely lower case,
      and not coded or abbreviated.
Multiple words may be used to specify dialect.
A blank defaults to English.

The value does not apply to header, footer, or transmitted CCS.

* Languages are those that are recognized as such in
          peer-reviewed
          printed
          mainstream journals and books
          that serve the linguistics scholars community;
e.g., The World's Major Languages, edited by Professor Bernard Comrie, 1987, Oxford University Press. Other types of references are not acceptable, and the easily malleable internet is certainly not acceptable even when claiming to present a printed document.

Extension For System Support :
      It may identify system languages and dialects.
      It may identify system protocols and dialects.
      System designators precede human language names.
      System designators may be abbreviated.

Separator Option :
      An optional comma separator is permitted.
      If a separator is used, then it will be used appropriately
      through the entire string.
      Example:   smtp, hausa, zaria
          A system protocol, a human language, and its dialect.
      Example:   edi, phone bill, motu, hiri motu
          A system protocol, dialect, human language, and dialect.
      Example:   smtp soap sql
          A system protocol, protocol, and language.

Strongly Recommended :
      Multiple specifications are normally red from left to right beginning with the topmost enclosing element. For example, edi is the protocol that contains the phone bill dialect that transports the motu language in the hiri motu dialect phone bill.

( Recognition by the technical community that no language can contain the power and beauty of all of Man's languages, and that preservation of our endangered languages is worthy unto itself. )

_________________________
_________________________
Protocol
Section
Transmission Envelope

Address : jragan.com/syslink.htm#S.30.00

-- . --

Protocol
Section
Transmission Envelope
Sub-Section
General Specifications

Address : jragan.com/syslink.htm#S.60.12

-- . --

The following terms are re-specified for clarity :
      Envelope
      Payload
      Content
      Header
      Footer

Envelope :
      The envelope consists of a header and a footer.
      The envelope is required for payload transmission.
      All payloads are enclosed within the SysLink envelope.

Header :
      The envelope header is every byte from, and including, the first byte in the transmission to, and including, the header terminator element with its terminators.

Footer:
      The envelope footer is every byte from, and including, the first byte in the footer to, and including, the last byte in the transmission.

Payload :
      The payload is that which the application system intends to send or communicate.
      The nature and character of the payload is specifically and intentionally not addressed by this protocol.

Envelope Content :
      Everything between the envelope header and footer.
      The content is the payload and(or) SysLink Command and Control Strings (CCS).
      The content will not be null, blank, or empty.

Required Data :
      Asterisks mark elements that must contain the specified data.
      Those values will not be empty, null, or spaces.
      Optional elements may be empty.

Identifiers :
      See the Universalization section.

Permitted Characters:
      See the Universalization section.

Exclusion :
      The specification of an element's content is also a statement that only the specified content is permitted. No description, label, qualifier, quantifier, etc. is permitted. A CoreDate is recommended.

Encryption And Compression :
      See the Universalization section.

Protocol
Section
Transmission Envelope
Sub-Section
Envelope Header

Address : jragan.com/syslink.htm#S.30.20

-- . --

Envelope Header :
      The envelope header is composed of twenty-five elements.
      Each element is dedicated.
      Element sequence is fixed.
      The elements are of indeterminate length.
      Each of the 25 elements has a terminator string.
      That terminator string is ASCII characters 13 and 10.
      Those characters may not appear elsewhere in the header.

(Developers, please note that the slot architecture is emphatically not a name-value pair architecture.)

( The numbers and asterisks below are not part of the elements and are only to ease comprehension, administration, and development. Asterisks identify those elements that must be populated, and optional elements may be empty.)

Protocol
Section
Transmission Envelope
Sub-Section
Envelope Footer

Address : jragan.com/syslink.htm#S.30.40

-- . --

Footer:
      The envelope footer ends the entire transmission.
      Nothing will follow the footer.
      It is composed of three required elements.
      Each of the 3 elements is terminated by characters 13 and 10.

1     An ASCII character 127 is the initial footer delimiter.
2     Header and footer envelope identifiers must be identical.
3     The last element contains the CCS literal
            ** stop syslink transmission**

_________________________
_________________________
Protocol
Section
Command And Control

Address : jragan.com/syslink.htm#S.50.00

-- . --

The following Command and Control Strings (CCS) are part of the protocol. Non-canonical CCS are not disallowed, but only those listed below are within protocol.

Caution:
      The toleration of non-canonical CCS does not imply support. Non-canonical CCS will be over-ridden at any time and without notice by future protocol upgrades regardless of usage volume and regardless of financial disruption.
      The protocol lexicon is specifically designed with considered intent to not support identifiable companies, industries, activities, organizations, governments, software, protocols, or hardware.
      A non-canonical CCS that supports one of those is certainly in danger of being over-ridden or of being declared invalid.

Required CCS:
      The use, and(or) response to, is required for only some CCS. But all canonical CCS must be recognized as valid members of the protocol, and no non-canonical CCS must be recognized.
      Required use is relaxed in some cases only to support security, and use in those cases may be recommended.

An envelope that contains a CCS will contain only that CCS and its parameters, if any. Refer to the CCS stacker for multiple CCS support.

To facilitate development and debugging, the CCS lexicon is designed for human readability as well as for machine use.

All CCS are precisely 30 characters. Where a terminator is specified for a CCS, the terminator is not part of the thirty characters.

Where parameters are required, the thirty characters are immediately followed by parameter brackets. The left bracket is a right pointer (>) and the right bracket is a left pointer (<). The parameters are placed within the brackets; i.e., >parameter<.

CCS are case-sensitive literals. They are entirely lower case for uniformity, to ease processing, to reduce system bugs, and because lower case is easier for people to read. Each of them includes two asterisks at each end. Spaces within the strings are specific.

The envelope open and stop strings are included in the following list for clarity. The other CCS are transported inside the envelope.

The following list of literals is published to assist with space placement within each string. It is hoped that the on-screen display will allow valid copying. Be wary of the double space.

        ** open syslink transmission**
        ** stop syslink transmission**
        ** open new syslink session **
        ** end this syslink session **
        **reverse connection to port**
        **syslink session identifier**
        ** session request accepted **
        ** execute local app command**
        ** resend lost transmission **
        **syslink error notification**
        ** information return query **
        ** information query return **
        ** identification requested **
        **identification is enclosed**
        **comm check please respond **
        **comm check 30 chr response**
        **authenticate**authenticate**
        ** authentication enclosed  **
        ** encryption specification **
        ** initialize app or system **
        **stop now. unload now. die.**
        ** transmissions size limit **
        ** denial of a transmission **
        ** operation status follows **
        ** ** local error report ** **
        ** acknowledge transmission **
        ** * server return begin. * **
        ** * server return cease. * **
        ** ccs stacker stack framer **

Do NOT use the following list. Its only purpose is to verify the above spaces, which can be hard to identify. Each space has been replaced by a character. Do NOT use this list.

        **#open#syslink#transmission**
        **#stop#syslink#transmission**
        **#open#new#syslink#session#**
        **#end#this#syslink#session#**
        **reverse#connection#to#port**
        **syslink#session#identifier**
        **#session#request#accepted#**
        **#execute#local#app#command**
        **#resend#lost#transmission#**
        **syslink#error#notification**
        **#information#return#query#**
        **#information#query#return#**
        **#identification#requested#**
        **identification#is#enclosed**
        **comm#check#please#respond#**
        **comm#check#30#chr#response**
        **authenticate**authenticate**
        **#authentication#enclosed##**
        **#encryption#specification#**
        **#initialize#app#or#system#**
        **stop#now.#unload now.#die.**
        **#transmissions#size#limit#**
        **#denial#of#a#transmission#**
        **#operation#status#follows#**
        **#**#local#error#report#**#**
        **#acknowledge#transmission#**
        **#*#server#return#begin.#*#**
        **#*#server#return cease.#*#**
        **#ccs#stacker#stack#framer#**

_________________________
_________________________
Protocol
Section
CCS Lexicon,
Syntax Reference,
And Usage Guide

Address : jragan.com/syslink.htm#S.60.00

-- . --

Protocol
Section
CCS Lexicon
Sub-Section
Required CCS

Address : jragan.com/syslink.htm#S.60.03

-- . --

The CCS that are listed in this sub-section are required. Their use is not required, but a SysLink participant will be aware of, be able to use, and be able to respond correctly to these CCS.

__________________________________________________
CCS: ** open syslink transmission**

Address : jragan.com/syslink.htm#S.60.06

-- . --

Compliance:   Required.   System must be able to participate.

This string is used only within the envelope header at the beginning of a transmission to declare the beginning of a single continuous transmission. (Note the difference between a transmission and a session.)

__________________________________________________
CCS: ** stop syslink transmission**

Address : jragan.com/syslink.htm#S.60.09

-- . --

Compliance:   Required.   System must be able to participate.

Used only within an envelope footer at the end of a transmission.

__________________________________________________
CCS: ** open new syslink session **

Address : jragan.com/syslink.htm#S.60.12

-- . --

Compliance:   Required.   System must be able to participate.

The complete command is in the form:
          ** open new syslink session **>specification<
where specification is enclosed by the pointers, and is a proposed session ID.

The protocol requires that the systems open the communication session. It may be opened either by this command or by the "reverse connection" command. If this command is used, then the "reverse connection" command may be sent later.

If the envelope header contains a session ID and there is a session ID in this request, then the two must be identical.

Although the enclosure is required, an empty session ID may be proposed by leaving the enclosure empty. The presence of a session ID is a proposal. If it is present, then it may not be ignored. The recipient may elect to use it, or may counter-propose a session ID in a reply, or the session request may be entirely denied or ignored.
      ( Note that SysLink specifies no null character. Therefore, a space in the enclosure is an error as specified by the SysLink ID specification, but an empty string is not an error. )

Refusal:
          The receipt of an error notice in response to this transmission should be recognized as a refusal. Although a session has not been established, it is recommended that the recipient of that error notice terminate the proposed session for clarity if security permits.

Acceptance:
          A notice of explicit acceptance from the interlocutor is not required.
          Receipt of any response that is not a challenge and not an error notice is an explicit acceptance of the request.

No response:
          The recipient may elect to not respond for security.

( See also:
          **syslink session identifier**
          **reverse connection to port** )

Examples:
      ** open new syslink session **><
      ** open new syslink session **>an ID spec<

__________________________________________________
CCS: ** end this syslink session **

Address : jragan.com/syslink.htm#S.60.15

-- . --

( Release 140125 replaces **break our comm connections** because the perceived semantics of the old one were too unlike the actual operation. )

Compliance:   Required.   System must be able to participate.

Sending this command to the interlocutor ends the communication session.

When that string is sent or received, the system is expected to immediately initialize communications without response or notice, but the receiver is allowed to return the same message.

( Recommendation:
          Transmissions may be delayed by activity in the recipient or by the infrastructure even when the infrastructure appears healthy, so it is possible that multiple sessions may be opened unintentionally. Therefore, the inclusion of the datetime in the envelope header is strongly recommended. Above all, if the session has an identifier, then its inclusion is recommended.)

__________________________________________________
CCS: **reverse connection to port**

Address : jragan.com/syslink.htm#S.60.18

-- . --

Compliance:   Required.   System must be able to participate.

The complete command is in the form:
          **reverse connection to port**>specification<
where specification is enclosed by the pointers, and is the port specification.

Purpose:
          Provides a contraplex link specification for a session.

Specification:
          On computers that use the socket port concept, the port is an integer as specified by the appropriate protocol.
          It may also be used by other systems that may or may not be computers and that use a conceptually similar construct to specify an available or authorized system entry point.

If the session has not been opened and established, then receipt of this CCS will constitute a request to open a session. The establishment of a reverse connection will be construed as an acceptance of the request for a SysLink session.

Refusal:
          The receipt of an error notice in response to this transmission should be recognized as a refusal. Although a session has not been established, it is recommended that the recipient of that error notice terminate the proposed session for clarity if security permits.

Acceptance:
          A notice of explicit acceptance from the interlocutor is not required.
          Receipt of any response that is not a challenge and not an error notice is an explicit acceptance of the request.

( See also:
          ** open new syslink session ** )

__________________________________________________
CCS: **syslink session identifier**

Address : jragan.com/syslink.htm#S.60.21

-- . --

Compliance:   Required.   System must be able to participate.

The complete command is in the form:
          **syslink session identifier**>specification<
where specification is the session identifier.

See Unique Identifiers in the Universalization section.

As specified by the SysLink ID specification, the enclosure may not contain a blank. However, it can be empty. An empty enclosure may be transmitted to contest a received ID proposal.

If this command is sent by either party without contest, then the enclosed value will become the identifier of the current SysLink session until session termination. The session identifier will be included in the header of every transmission.

Transmission of this command will constitute acceptance of a session request although its identifier may be under contest.

( See also:
          ** open new syslink session **
          **reverse connection to port** )

Examples:
      **syslink session identifier**><
      **syslink session identifier**>an ID spec<

__________________________________________________
CCS: **comm check please respond **

Compliance:   Required.   System must be able to participate.

This control statement may be initiated by client or server to verify a functional communication link. The command will constitute the entire message.

__________________________________________________
CCS: **comm check 30 chr response**

Address : jragan.com/syslink.htm#S.60.27

-- . --

Compliance:   Required.   System must be able to participate.

This is the expected response to a communication check if the system chooses to respond. The entire message will consist of only the response.

The identification of the request may be in the envelope header.

Failure to respond is not an error within this protocol.

__________________________________________________
CCS: ** session request accepted **

Address : jragan.com/syslink.htm#S.60.42

-- . --

Compliance:   Required.   System must be able to participate.

The complete command is in the form:
          ** session request accepted **>specification<
where specification is a session identifier.

There are other means of granting a session. This CCS may be preferred because it is dedicated and explicit.

This response to a session request instantiates the session.

The session identifier may be empty, or it may be that suggested by the requestor, or it may be a new identifier. In any case, it will be used for the duration of the session.
      Technically, this has opened a session. Therefore, if the requestor declines the specification, then the specified session must be ended by both parties.
      ( SysLink specifies no null character. Therefore, a space in the enclosure would be an error as specified by the SysLink ID specification, but it may be empty. )

( See also:
          **syslink session identifier**><
          **reverse connection to port**><
          ** open new syslink session **>< )

Example:
          ** session request accepted **>identifier<

Protocol
Section
CCS Lexicon
Sub-Section
Optional CCS

The CCS that are listed in this sub-section are not required. A SysLink participant will be aware of them so that they are not considered erroneous. However, optionality does not allow their replacement.

Optionality is determined by the spectra of programming ability and security. Some are highly recommended.

Where security is not compromised, highly recommended is the ability to return a generalized response to optional and declined CCS to maintain the communication thread. Possibilities are the local error report and the transmission denial.

__________________________________________________
CCS: ** execute local app command**

Address : jragan.com/syslink.htm#S.60.33

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** execute local app command**>specification<
where specification is the app command string.

The specification is placed in the following data structure of six elements.
      The name of the target app.
      A vertical bar. (Called a pipe by old Unix hackers.)
      The command.
      A vertical bar.
      The parameters for the command.
      A vertical bar.

This permits commands outside the protocol to be sent to a system for execution. The receiver is expected to extract the command and pass it to the target for execution.

The target app is required. It may be any system including self.

The command and the parameters are optional, but the vertical bars are required. The final bar immediately precedes the specification closure.

( See also:
          ** information return query ** )

Example:
      Tell AxleBase to run a SQL query.
          ** execute local app command**> AxleBase | ExecuteSql | select * from table where something is null |<
      (Additional spaces in the example are neither required nor disallowed.)

Example:
      ** execute local app command**> AxleBase | Shutdown | |<

__________________________________________________
CCS:** resend lost transmission **

Address : jragan.com/syslink.htm#S.60.36

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** resend lost transmission **>specification<

This is a request for the interlocutor to resend a lost, garbled, or suspect transmission after the session has been established. The session may be serialized. The sender and recipient of this CCS will cease transmissions pending compliance or rejection of this request.

The inability to comply for any reason will precipitate rejection, local error, or session termination by the recipient, but it is not a protocol error. Both respondents will then elect to continue or terminate the session.

Specification:
      May be empty, blank, a serial number, or an identifier.
      A blank or empty string specifies the last transmission.
      An identifier or serial number specifies a transmission.
      An identifier or serial number prefixed by the string
          "-after-" specifies the subsequent message.
      The prefix string "-all-after-" specifies all messages after
          the identifier or serial number.

Retransmission:
      The retransmission will have a new header.
      The resend element will identify the original message.
      The response identifier will identify the resend request.

Examples:
      ** resend lost transmission **><
      ** resend lost transmission **>2681<
      ** resend lost transmission **>-after-2681<
      ** resend lost transmission **>-all-after-2681<
      ** resend lost transmission **>Qca0B0xofeegSAdx2i2b9xl<

__________________________________________________
CCS: ** information return query **

Address : jragan.com/syslink.htm#S.60.42

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** information return query **>request<
where request specifies the information to be returned.

This is a request for information. It carries the specification of the desired information within itself.

Specification:
      A request must be present to support security.
      Protocol control of the request is weak to support massively different organizational and cultural needs.
      However, failure to support SysLink's human-readability requirement is just cause for rejection of the entire communication session as a security risk.
      Categorical specification support may be provided within protocol such as the following request for service information.

Discovery:
      A formal service discovery may be accomplished by using the following character string as the information specification.

( See also:
          ** execute local app command** )

Example:
      The location for the demonstration databases can be known only by the server, so before beginning a database build and test, AxHandle sends the following request:
      ** information return query **>dbroot<
      The AxServer demonstration server response is:
      ** information query return **>\\server19\c:\axserver\<

__________________________________________________
CCS: ** information query return **

Address : jragan.com/syslink.htm#S.60.45

-- . --

Compliance:   Optional.   A refusal response is recommended.

The complete response is in the form:
          ** information query return **>information<
where information is the requested information or a response.

This CCS is a response to ** information return query **.

The transmission header, slot 13, may contain the identifier of the request transmission to which this is a response.

Note:
      The request is required to carry an explicit request, so it is recommended that you treat an empty request as suspicious.

Example:
      The location for the demonstration databases can be known only by the server, so before beginning a database build and test, AxHandle sends the following request:
      ** information return query **>dbroot<
The AxServer demonstration server response is:
      ** information query return **>\\server19\c:\axserver\<
A phone number is requested from a directory service:
      ** information return query **>Carl Chisolm<
To which the response is:
      ** information query return **>501-227-8237<

__________________________________________________
CCS: ** identification requested **

Address : jragan.com/syslink.htm#S.60.48

-- . --

Compliance:   Optional.  

This is a request to the interlocutor to return its identification. Response failure is not a protocol error (, although it may be an application error).

The receiving app may require the sender's id and authentication in the header with this command, but this protocol does not require them.

__________________________________________________
CCS: **identification is enclosed**

Compliance:   Optional.  

This is a response to a request for identification. The identification will be in the envelope header. Response failure is not a protocol error.

__________________________________________________
CCS: **authenticate**authenticate**

Address : jragan.com/syslink.htm#S.60.54

-- . --

Compliance:   Optional.  

The complete command is in the form:
          **authenticate**authenticate**>specification<
where specification is enclosed by the pointers.

Receipt of this command is a request for authentication.

Contents of the specification will depend upon when the authentication is wanted and upon the nature of the applications. Some apps, such as AxleBase can authenticate without input, but some require an authentication seed from the requestor. A vertical bar indicates a seed or challenge.

Start String:
      Optional.
      Is the literal string "start".
      Can be used alone.
      Can prepend a specification.

Response Types:
      A single immediate authentication.
      Begin authentication of transmissions without an immediate response.

A single immediate CCS authentication is expected:
      If the specification is empty,
      or if the specification is a single vertical bar,
      or if it is a single vertical bar followed by a value.

Begin envelope authentication of all subsequent transmissions:
      If the specification is the start string,
      or it is the start string followed by a vertical bar,
      or it is the start string, a bar, and a value.

( See also:
          ** authentication enclosed **
          The envelope authentication slot. )

Examples:
      **authenticate**authenticate**><
      **authenticate**authenticate**>|<
      **authenticate**authenticate**>|xyz123<
      **authenticate**authenticate**>start<
      **authenticate**authenticate**>start|<
      **authenticate**authenticate**>start|xyz123<

__________________________________________________
CCS: ** authentication enclosed **

Address : jragan.com/syslink.htm#S.60.57

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** authentication enclosed **>specification<
where specification is the authentication string.

This is a possible response to a request for authentication.

( See also:
          **authenticate**authenticate**
          The envelope authentication slot. )

__________________________________________________
CCS: ** encryption specification **

Address : jragan.com/syslink.htm#S.60.60

-- . --

( This command protocol is still under review and should be expected to change.)

Compliance:   Optional.  

The complete command is in the form:
          ** encryption specification **>specification<
where specification is enclosed by the pointers, and is either an encryption specification or is blank.

This is a request to the interlocutor for encryption of subsequent transmissions.

After this command is transmitted, the transmitting system will expect encryption until the command is rescinded. Rescission is accomplished by transmitting the command with the "stop" string in the specification position.

__________________________________________________
CCS: ** initialize app or system ** Address : jragan.com/syslink.htm#S.60.63

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** initialize app or system **>specification<
where specification specifies the target app or system.

This commands the recipient to initialize itself, an embedded app, or the operating system.

The app specification is outside this protocol.

Example:
      When AxleBase is in a server, operation and communication control is in the remote control console. That control console is in the AxHandle demonstrator.
      The AxHandle demonstrator likes to initialize AxleBase in the server after heavy-duty cycles and in some job streams. When AxServer receives the command
      ** initialize app or system **>AxleBase<
he stops, unloads, and reloads AxleBase. When he receives the command
      ** initialize app or system **>computer<
he reboots the computer.

__________________________________________________
CCS: **stop now. unload now. die.** Address : jragan.com/syslink.htm#S.60.66

-- . --

Compliance:   Optional.  

The receiving app, server or client, is expected to respond to this command by unloading itself and any client software. There is no provision for a restart. (See the initialization command for a restart.)

If the server is running a job, then compliance may not be possible. Therefore, a comm-check is recommended after sending the command.

__________________________________________________
CCS: ** transmissions size limit ** Address : jragan.com/syslink.htm#S.60.69

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** transmissions size limit **>specification<
where specification is the limit.

Allows specification of the maximum number of bytes that can be in each inbound transmission. That size applies to the entire envelope with its contents. The specification will contain digits and only digits.

No specification or a specification of zero means that there is no limit. The value is not negotiable. Each side may set a limit for its inbound traffic.

If a transmission exceeds the specification, then the interlocutor will be expected to discard the transmission. Such rejection may or may not, at the discretion of the recipient, cause the return of an error notice.

The specification will remain in effect for the duration of the communication session.

( See also:
          ** ** local error report ** ** )

__________________________________________________
CCS:< ** denial of a transmission ** Address : jragan.com/syslink.htm#S.60.72

-- . --

Compliance:   Optional.  

This states a refusal to comply. Its use is optional and it may be used as a response to any message.

The recipient may expect to find the number of the transmission to which it is a response in the header, but the sender is not required to send that information.

__________________________________________________
CCS: ** operation status follows ** Address : jragan.com/syslink.htm#S.60.75

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** operation status follows **>specification<
where specification is the report.

This transmits the state or status of an operation. It is provided for application-specific needs. The report specification is not addressed by this protocol.

( See also :
        ** ** local error report ** **
        **syslink error notification**
        The server envelope. )

Examples:
      ** operation status follows **>intermittent noise<
      ** operation status follows **>daily operation completed<

__________________________________________________
CCS: **syslink error notification** Address : jragan.com/syslink.htm#S.6076

-- . --

Compliance:   Optional.  

The complete command is in the form:
          **syslink error notification**>specification<
where specification is an optional error description.

This is for errors in protocol usage and not in communication or systems.

The specification is free-form and may be system-readable, but will be understandable by a person if not blank.

( See also:
  "** ** local error report ** **".
  "** operation status follows **"
  The server envelope. )

Examples:
**syslink error notification**><
**syslink error notification**>007 invalid ccs<
**syslink error notification**>007 ccs in message not valid<
**syslink error notification**>007 The CCS that was used in the transmission identified in the header has an upper case character.<

__________________________________________________
CCS: ** ** local error report ** ** Address : jragan.com/syslink.htm#S.60.77

-- . --

Compliance:   Optional.  

The complete command is in the form:
          ** ** local error report ** **>specification<
where specification is the report.

Allows reporting any type of local error to the respondent. It is provided for application-specific needs. The report specification is not addressed by this protocol.

( See also:
        ** operation status follows **
        **syslink error notification**
        The server envelope. )

Example:
      ** ** local error report ** **>storage media failed<

__________________________________________________
CCS: ** routing error commission ** Address : jragan.com/syslink.htm#S.60.78

-- . --

Under study or consideration and not implemented.
See proposal 24 in the Upgrade Proposals section.

A CCS dedicated to routing errors seems dictated by:
      Slot 22 of the envelope header.
      Eventual high traffic volume.
      Possible high error volume caused by :
          Potential complexity of SysLink Routes.
          Routing usage complexity supported by SysLink.
      The need for high speed processing of routing.

Compliance would be:   Optional.   Highly recommended.

The complete command would be in the form:
          ** routing error commission **>specification<
where specification describes the error.

Compliance would be:
      Public routers must comply.
      A secured router may or may not participate.
      Route requesters are not required to supply a return route.
      Error description is required with the CCS.
          Length is unspecified.

__________________________________________________
CCS: ** acknowledge transmission ** Address : jragan.com/syslink.htm#S.60.81

-- . --

Compliance:   Optional.   Highly recommended.

This declares that a transmission was received. The envelope header allows the acknowledged transmission to be named if desired.

An acknowledgment will not be sent if the inbound message requires a response. That response is implicit acknowledgment.

A response will never be made to an acknowledgment.

Transmittal of this CCS is also a transmission of a non-null value that accepts any specified terms and(or) acquiesces to any commands in the inbound transmission.

The use of this CCS is optional and is determined by the system that received the message. Where load and security permit, routine use of this CCS is recommended.

__________________________________________________
Protocol
Section
CCS Lexicon And Syntax
Sub-Section
Server Envelope

Compliance:   Required.   For server traffic only.

A server envelope manages server returns. The server envelope consists of a single element header string and a single element footer string. The header and footer strings conform to the Command and Control Strings format. Each is a thirty character literal. Each is terminated by ASCII characters 13 and 10.

The server envelope header is:
          ** * server return begin. * **
, and the server envelope footer is:
          ** * server return cease. * **

The server envelope is placed inside a transmission envelope. The server envelope is alone within the transmission envelope.

A server may return anything within the server envelope including application error messages. This protocol does not address the contents.

( The protocol does not address the nature or definition of servers. The protocol does not deny the ability of both interlocutors to be servers and(or) clients. )

__________________________________________________
Protocol
Section
CCS Lexicon And Syntax
Sub-Section
The CCS Stacker

Address : jragan.com/syslink.htm#S.60.87

last update 20230129
-- . --

Compliance:   Optional.   A rejection return is recommended.

( Presentation of the stacker is not a recommendation for usage. The stacker construct is deemed necessary for a complete and mature protocol despite the problematic nature of remote asynchronous system interaction. )

Purpose:
      The CCS stacker is a control string that enables the envelope to carry multiple Command and Control Strings (CCS).

Exclusivity:
      An envelope that contains a stack contains nothing else.

The stacker control string is:
          ** ccs stacker stack framer **
Like all CCS, the stacker string is a thirty character literal.
It is always terminated by ASCII characters 13 and 10 to insure valid processing splits.

The Stack Construct:
      An envelope content is a stack if, and only if,
          its initial characters are the stacker string,
          and each stacked CCS is terminated by the stacker string.
      The stack will contain at least one CCS.

Server Envelope:
      When a server envelope is part of a stacked transmission, the entire server envelope is treated as a single CCS.

Multi-Element CCS:
      Terminators and parameters of CCS are treated as part of their CCS by the stacker.

Security:
      Systems may meet the requirements for the current release while rejecting CCS stacks as a matter of course. A rejection notice return is recommended, but is not required.

Session Admin:
      Stacking working commands with administrative messages, such as a request to open a session, is discouraged, but is not disallowed.

Iteration:
      For security reasons, the stack is neither iterative nor cyclical. (Local app implementations are, obviously, free to over-ride this.)

Stack Ordinality:
      Determine ordinality by casting the stack as a string.
      Read that string from left to right.
      Ignore stacker strings.
      The first stack element is the first CCS that is red.
      The first element is number one.
      The last stack element is the last CCS that is red.
      Element numbers continue through the last CCS.
      Element numbers are sequential and consecutive.
      Ordinality is conceptual and inferred.
      Elements are not explicitly numbered.

Job Stream:
      The stack as a job stream is specifically not addressed by the protocol.

Size:
      The stack size is specifically not addressed by the protocol.

Example of a stacked transmission:
    ** ccs stacker stack framer **
        ** execute local app command**>
       AxleBase|CloseDatabase|<
    ** ccs stacker stack framer **
        ** initialize app or system **>AxleBase<
    ** ccs stacker stack framer **
        ** initialize app or system **>computer<
    ** ccs stacker stack framer **
        ** end this syslink session **
    ** ccs stacker stack framer **
This message conveys a stack of four commands. The fourth may not be needed if events transpire as planned, but is required by protocol. The stack construction suggests that the involved app developers mapped stack ordinality into execution sequence. (Line indents are only to clarify the example.)

Example of a stacked transmission:
    ** ccs stacker stack framer **
        ** execute local app command**>
        AxleBase|ConnectionString|domain = t:\test_db\domain\,
        database = load_test, password = test, user = me|<
    ** ccs stacker stack framer **
        ** execute local app command**>
        AxleBase|ExecuteSql|select count(*) from t_customer|<
    ** ccs stacker stack framer **
        ** execute local app command**>
        AxleBase|ExecuteSql|select * from t_log|<
    ** ccs stacker stack framer **
        ** execute local app command**>AxleBase|CloseDatabase|<
    ** ccs stacker stack framer **
This message conveys a stack of four commands. The database server will execute each query, returning the results before proceeding to the next command. (Line indents are only to clarify the example.)

End Of SysLink Protocol
The remainder of this document is not part of the protocol.
Click to return to table of contents at the top __________________________________________________
__________________________________________________

__________________________________________________
__________________________________________________

Appendices

The appendices are not part of the SysLink protocol.
They provide explication, expansion, and support for SysLink.

( Comments and suggestions will be received with appreciation. Do not be greatly concerned about linguistic correctness if English is not your native language. )

( This appendix is not part of the SysLink protocol. )

The Problem

The SysLink protocol is not particularly complex, but it is new and somewhat alien due to its newness. Reading and dwelling on it for a short while should make it comprehensible for most people. It is so simple, in fact, that its simplicity may be a problem because that simplicity hides the importance of enforcing compliance with all the details.

However, this implementation appendix exposes many network functions and protocols that are not normally seen or even cared about by most people, some of which were traditionally enclosed in expensive esoteric hardware. Then it combines SysLink with a few system design and programming tricks to encapsulate, express, and extend or enhance those functions and protocols. That is complex. And greater complexity is encouraged.

The objective is to empower local managers, owners, system designers, and programmers world-wide to control their own communications, and to tell developers how to build community servers, and that results in the complexity identified in the preceding paragraph. But notice that that complexity is not in SysLink, but comes from allowing free reign of the imagination to implement the SysLink power. The SysLink protocol and knowledge of the potential in software engineering made that possible. And it is hoped that the ideas presented will stimulate more creative thoughts in many of us.

For those who feel a bit intimidated, please do not give up. The objective seemed impossible even to the creator of SysLink when he began wrestling with the many concepts that he needed to understand and use. It is hoped that SysLink will create fun for many around the world, and that that fun will include your help in expanding our communications and security, especially to support the little man and the small business.

The reality is that the world of systems and system usage is a complex adults-only environment, but knowing that, with persevarence we can do this and have fun doing it.

A Suggested Solution

Focus :
      You will want to read this entire document, of course. But afterwards, it may be best to focus on specific areas to avoid the complexity of the entirety until you feel ready for it. You will find that most technologies are presented as simply as possible to help everybody advance into the areas that are opened up by SysLink.

Getting Started :
      Initially, focus on the protocol proper. Study it while giving no thought to this appendix and ancillary issues. After all, the protocol is what this document is about. Start with the Technical Objectives and Non-Technical Summary sections.

Implementation Appendix :
      After absorbing the protocol, then address its implementation in this appendix. You might want to read all of it, but note that you do not need to entirely absorb or even understand everything.

One detail may be nagging at the back of your mind, and if you are not extremely technical, then you might not be able to articulate it. That detail is the fact that the tremendous complexity of the vast TCP/IP infrastructure is hardly mentioned. That was no accident. Ignore it for the moment because it is working nicely and you will find that it and SysLink fit together.

Programming Details :
      If you are not employed in programming or system design, then you do not need to understand the programming section. A manager who wants to employ SysLink could leave that section to his specialists. But if so inclined, some knowledge of it might assist the manager in insuring that certain key elements are addressed. System designers and programmers should certainly concentrate on the details of that section.

Location :
      If all of this is new to you, you may be wondering where these systems (programs) will be running. They will be running on any computer on which you want to run them. If your program is a router that you want to run on a desktop computer that can carry the load, attach it to the network and do it.

Advanced Topics :
      Few people will ever need to know about everything covered in the Advanced Topics chapter. But it would be a good idea for anybody who manages, designs, or develops for communications to at least know about the existence of the subjects covered.

Routing and Security :
      The SysLink concept has opened major opportunities in the Routing and Security sections that are already seized upon world-wide and are being investigated in academia and computer science. If you are engaged in routing or security technologies, then you will want to be aware of the SysLink advances.

Modularization :
      If you are a manager, then think in terms of modules, chunks, and entities, which is what your developers will do. The actual implementation of the advanced topics will not be in a monolithic entity in an antique mainframe or "cloud", but in small manageable modules and module groups that are determined and defined by function, ownership, and management responsibility, and that may run on inexpensive computers. If properly designed and built, their modularization will give them portability, ease maintenance, insulate against external disruption, and ease management.

Those modules will communicate to perform tasks for each other. Developers will design each one so that a faulting module will report the problem, logically-adjacent modules will report it from their perspectives, there will be a diagnostic path to it, and when needed, a backup will automatically replace the failed module.

At this point, the manager is wondering how all those distributed autonomous modules will be managed. An unthinkable option is to return to the pre-PC mind-stultification of the mainframe, or to the bureaucracy of the "cloud". This writer has had positive hands-on experience designing and building small autonomic systems that monitored many larger systems, and that can also be envisaged as modules. A major function of those control modules was to notify an administrator :
    When an aberrant event was beyond the corrective abilities
        of the control system.
    When interesting anomalous events occurred.
    When the control module replaced, or failed to replace,
        a failed module.
An important lesson learned by the writer is to never rely on operating systems to report problems. After he learned how to build them, his control systems were far more dependable than were the operating systems and advised department heads about their malfunctioning operating systems.

There are many ways to manage replacement modules. For example, a replacement module can be staged in a live, but off-line mode as a hot-swap unit. The control module would then be notified of the replacement's address and the address of its active counterpart(s). Failure of the active module would cause the control module to insure that it is dead, bring the next-available replacement on-line in its place, and notify administrators. Details of activating the replacement, such as address-handling will vary according to function, management-style, and location.

Mental modularization will simplify the workings of the system and ease its management. And this far greater benefit may arise from it:. Exposure of the previously hidden network functions may stimulate thousands of minds to create network improvements and new functions. No bureaucracy can match the creativity and productivity of God's unimpeded and rewarded natural growth.

Finally :
      Let your imagination soar. We can build your dream.

See the Presentation section of the Administrative Text chapter.

SysLink was made free only to get it out to the community. There was no other way, and that act was intended in no way to indicate the value of your work. A man should be rewarded for his work. The great failed experiment in communism by the Union of Soviet Socialist Republics (The Soviet Union) demonstrated for all time the fact that society benefits most when the individual benefits.

If you use this protocol to invent, create, or build something useful, then please demand payment for it.

Those who think that "open source" is a service delude themselves by ignoring the thousands of men who live in poverty because the billionaires and the big corporations use their "open source" code instead of paying for honest labor. That is voluntary enslavement. The creator of SysLink gave it away with his blessings, but he is letting time destroy his unsold software because he will not give that away.

1. Beat the billionaires to market.
2. It cannot be buggy.
      You cannot afford to alienate the market, so you must
      perform better than the big name brands.
3. Create a means to upgrade your product in a
      production environment.
4. React immediately to a problem or bug report.
      Work through the night and apologize.
5. Remember us when you become a billionaire.

( This appendix is not part of the SysLink protocol. )

( Comments and suggestions will be received with appreciation. Do not be greatly concerned about linguistic correctness if standard English is not your native language. )

Many are failing to understand, so be aware that SysLink :
      1. Is independent of low-level network protocols.
      2. Is independent of hardware technology.
      3. Is a universal application interface.
That allows it to run on any infrastructure regardless of networks and protocols, and allows it to be used by any system.

Communications, security, and system development are a dangerous combination. Perhaps the beginning developer should take these suggestions seriously to protect himself.

For the advanced developer, it is hoped that these suggestions may provide a quick start and some insight into the protocol's design.

Programming Language :
      The design objective was to allow nearly any programming language to build a SysLink interface or server including simple uncompiled languages.

The subjects of the next three paragraphs are tightly intertwined, but it may be helpful to see them addressed separately.

1. Inter-System Interface :
      SysLink intentionally incorporates two extreme and opposing inter-system interface methods. One is temporally loose and allows extraordinarily long quiet periods in a communication session without tying up system resources. The other is tight local control that allows a local system to unilaterally and abruptly end a session. Together, they address extreme needs of various communication scenarios. They do not necessarily conflict with each other, and are designed into the protocol as simultaneous requirements that the developer and his manager should address.

2. Fault Tolerance :
      SysLink offers extreme security and extreme flexibility. For example, SysLink is happy to wait a month for a data return when the network crashes. If the network recovers, SysLink will resume with the last system state. Those extremes are adjustable and should be addressed in the design phase.

3. Management Technique :
      The developer's job may be eased by knowing that a very old management protocol called "Management By Exception" is built into the design. That means that, after we put a system into production, we want our attention to be directed to it only when it has a problem. The intent was to support unattended autonomous systems where needed.

An Implementation Suggestion :
      The requirements of the protocol are minimal, but books could be written about its theory and implementation. Therefore, if you are already communicating, you might consider first building a minimal system and getting it on line and operational. Then close other ports and open a SysLink port with your little system behind it. After all appears operational, other SysLink features can be implemented until your system meets your control and security needs. This is not a recommendation, but it might assist small organizations

Have fun.

The protocol specifies no implementation method or architecture.

Unlike others, its claim to be an application layer protocol is not a figure of speech. It is intended for ease of use by the same people who program and manage applications. It can be implemented as part of an application as easily as it can be implemented in a stand-alone server.

The AxleBase* database manager has multiple interfaces, one of which is a SysLink interface. In that implementation, when the SysLink interface has been chosen, AxleBase accepts entire SysLink transmissions, decrypts, parses, validates, authenticates, and distributes the envelope payload, done entirely within the AxleBase object. Specification of that interface causes the system to reject extra-protocol transmissions as part of the security. Database returns are made entirely within the SysLink protocol, which can carry various database protocols.

That implementation offers :
      Extremely tight communication security.
      AxleBase encryption and authentication functions.
      Simplification of the host in which AxleBase is embedded.

Because that processing follows a convoluted overlapping path between apps, the complexity of that logic path makes debugging unusually difficult. Therefore, that architecture is recommended only where needed.

A more practical implementation might be as a small stand-alone SysLink object. The AxleBase implementation is more secure, but the stand-alone implementation might be simpler and could be generalized to service many kinds of systems. It could be distributed to managers who need local communication solutions.

Organizational servers can also be built to control general access. Where high levels of security are needed, departmental servers can be deployed within an organization.

The protocol is designed for flexible implementation as needed.

( AxleBase*)

_________________________
Appendix
Protocol Implementation Tutorial
Chapter
Programming Suggestions & Techniques
Section
Feasibility Testing In AxleBase



Address : jragan.com/syslink.htm#A4.30.00
-- . --

A SysLink interface was built into AxleBase* to study :
      Architectural placement of SysLink.
      A low-cost VPN.
      Autonomic VPN control by a database manager.
      Protocol performance.

Traffic Flow :
      A local socket server receives a network transmission.
      The server hands it to the AxleBase SysLink interface.
      AxleBase then
              decrypts,
              validates,
              parses,
              evaluates and re-validates,
              and runs the SQL query.
      AxleBase places the return in an encrypted envelope.
      Hands it to the socket server with delivery instructions.
      The server transmits it.

Location :
      AxleBase is specifically designed to be embedded in any host application that needs a database manager. Test hosts were built in the lab and AxleBase was embedded in them.
      AxServer is a simple database server for remotely presenting AxleBase databases.
      AxHandle is a general purpose, GUI based, local database app that can create databases, run long-term unattended tests such as dataset builds, and query and command AxleBase. AxHandle can also operate as a client to the AxServer database server.
      Each app contains a socket server that sends and receives for AxleBase's SysLink interface.

This is a feasibility study using AxleBase, and not a recommendation. The VPN interface may be removed from AxleBase when time permits because AxleBase does not require it.

AxleBase development and testing traffic was run through the SysLink interface for several years. Queries and commands were received, processed, and desired datasets were returned by AxleBase without error. Operation was so seamless that the developer forgot that the SysLink interface was being used, which is why it was tested so thoroughly.

Test Environment :
      A segmented high speed switched network.
      AxHandle contains a high speed scripted test system with hundreds of tests that is routinely run to build remote databases, run SQL, etc.
      Also, customized tests are run against very large tables that return substantial datasets of millions of rows.
      Some tests use multiple remote database servers, each embedded with the AxleBase - SysLink interface.
      ( Test data is on the AxleBase test page.)

Findings Of Interest :
      Low cost SysLink interfaces and servers are feasible.
      Design and coding of the interface was more complex than expected due to the convoluted logic flow and data flow between server, SysLink, and AxleBase. It could be simplified by placing the protocol in a stand-alone SysLink server.
      However, the SysLink interface embedded in AxleBase created a very secure database manager, with that interface controlled entirely by AxleBase, which is controlled by the local database administrator.

Impact On System Speed :
      The system speed differential was not tested.
      A tentative subjective assessment is that performance of the database manager would seem to the end user to be unchanged. As noted above, it was forgotten in the AxleBase lab for several years that the SysLink interface was being used.

( AxleBase*)

This topic is not for beginners. The purpose of this topic section is simply to highlight the fact that the SysLink protocol does not limit the number of participants in a session.

However, management of a multi-node session may become more complex than the management of multiple sessions to accomplish the same objective. For example, by definition, it ceases to exist when both respondents end it. That can be interpreted to mean that it ceases to exist for those respondents that ended it, but the system designer must express and control that interpretation in the design of his system.

This is certainly not a simple broadcast ability for servers. SysLink requires the explicit establishment of a session between the session participants that recognize each other as the other interlocutor in the session.

Therefore, although the multi-node session is possible and may serve special complex needs, it is currently not recommended.

( Reminder :   Appendices are outside the protocol. )

Receiving and routing SysLink transmissions can be deceptively simple. That apparent simplicity can lull the system developer into serious traps that will be sprung by the arrival of the malicious, the deviant, and the complex. The developer must keep in mind at all times the fact that the SysLink protocol is an interface to the world.

Perhaps this is obvious, but it should be noted for beginners that SysLink is designed to allow unattended system processing. Although easily red by a person, it is designed to allow your system to automatically validate, clear, parse, and route an arriving transmission, or reject it with appropriate action.

Whereas the construction of an outbound transmission is fairly straightforward, the safe and accurate processing of an inbound transmission is always potentially complex.

The following processing is simpler than it may, at first, seem. Inbound and outbound processing should be expected to run for a fraction of a second per transmission even on desktop computers.

If you use SysLink, you should require its use universally as you move toward communication management, and perhaps toward secure communications.

Some possible actions are :
      Tell interested parties that you will adopt a SysLink interface.
      Give your projected turn-on date.
      Build your system to automatically respond to non-SysLink messages with your requirement. (You may want to remove this after your system is secure.)

In addition to other contents, those messages should contain a link to the SysLink protocol document. Until the protocol is given to a committee for maintenance and safekeeping, that address is :

Caveat :
      Before transmitting those messages, consider how they will impact your security if you implement SysLink security. They will not compromise SysLink, but they may prompt criminals and governments to begin counter-preparations inside your system before you can implement strong SysLink security.

Appendix
Protocol Implementation Tutorial
Chapter
Programming Suggestions & Techniques
Section
Processing Inbound Traffic
Sub-Section
Processor Load



Address : jragan.com/syslink.htm#A4.50.20
-- . --

With tri-level encryption and thousand-character authentication, the AxleBase feasibility study routinely processed SysLink transmissions in a fraction of a second on turn-of-the-century desktop computers. Transmissions were system commands, SQL queries, and encrypted data returns.

A minimal transmission using only the mandatory elements of the envelope will be only 208 characters, approximately.

Add to that the contents of any desired optional element. For example, each additional identifier will contain sixty characters, perhaps twenty characters for a machine name, etc.

Add to that the expected size of the envelope contents. Administrative exchanges can be negligible, but SysLink is also designed to handle your very large transmissions of nearly any size.

Add to that the overhead added by security measures. That will be determined by your encryptor. In some cases, the encryptor may reduce the transmission size. The protocol also allows compression of the contents and(or) of the entire transmission.

SysLink is designed to carry anything, including binary executables and operating system control strings. The SysLink programmer, therefore, does not know what to expect. Literally, anything can be transmitted in the envelope including malicious executable code and hardware control codes. Therefore, the programmer and his system must avoid the envelope contents until the envelope is stripped, parsed, validated, and authenticated.

You will find in the following sequence of operations that reads are done one character at a time. SysLink is specifically designed to allow that, so your processor can read an inbound transmission from an external disk with fingertips and forceps. There should be no blocks of data or code in RAM until you are sure of the transmission.

Remember that the header elements are sequential. The sequence is fixed and mandatory. Some elements are optional, meaning that their use is optional, so they may be empty. If an element seems to be out of place, then the transmission is invalid and should be rejected.

The envelope is designed for safe processing through a sequence of small operations. Before doing the obvious things, perform the following sequence of operations.

The envelope and transmission, although conceptually and logically different, are defined by the protocol as mathematically congruent; i.e., the transmission can contain nothing but that which is defined within the envelope. By definition, therefore, the first two characters of the entire transmission are thirteen and ten. (The last characters are the transmission closure.) If they are not, then the transmission is invalid and should be rejected.

The next thirty-two characters are the literal SysLink transmission string and its two-character terminator. If they are not, then the transmission is invalid and should be rejected.

The check will thus proceed through the header elements until the lengths of the header, footer, and contents are red. At that point, the location of each header and footer delimiter character is known. If any length
      is not found,
      is not an integer,
      is zero,
      is illogical,
      or is any other deviant value,
then the transmission is invalid and should be rejected.

Use the header length to locate the header delimiter (terminator) by counting characters from the transmission start. Do this by walking one character at a time to the delimiter. If it is not at that location, then the transmission is invalid and should be rejected. Use no other method of finding that character because of possible conflicts with the message contents or because of malicious deviance.

From the rear of the transmission, walk backwards, by count, to read the transmission closure with its two-character terminator. If you do not obtain it in the correct character count, then the transmission is invalid and should be rejected.

Continue walking backwards to obtain the rest of the footer. You can do that by character count because the message identifier must match the one in the header, so you already have its length. You should now be sitting on the footer's delimiter. If not, then the transmission is invalid and should be rejected.

Compare the header and footer sizes to the expected sizes. If they do not match, then the transmission is invalid and should be rejected.

Be wary of the header and the footer until they are entirely validated. Extended characters can falsify counts for some programming languages.

Only English characters, Arabic digits, and ASCII characters 13, 10, and 127 at specified locations are permitted in the envelope. Not only is that an important part of the universalization of the protocol, it is a critical part of the protocol's security. If a character is found there that is not one of those, then the transmission is invalid and should be rejected.

Unicode would create additional security problems so it has been explicitly disallowed. Furthermore, since English characters and Arabic digits are required and are depicted by single ASCII values, there is no need for unicode. If unicode is encountered, then the transmission is invalid and dangerous and should be rejected.

Excess malicious characters could be appended or prepended in transit by padding the header or footer with false delimitation, and the contents might be expanded. At some point after the above steps are done, the header, footer, and contents must be separated. Verify all lengths against the specified lengths. If one does not match, then the transmission is invalid and should be rejected.

After identifying the header and footer, check for a superfluous internal header or footer. If one is found and was not expected, then the transmission is invalid and should be rejected. Detection of an unexpected superfluous internal header or footer should be considered serious enough to raise an alarm flag to the system administrators.

If the payload or contents are encrypted, then verify after decryption that the encryption was not hiding an original header or footer. If an unexpected header or footer is found within an encryption, then the transmission is invalid and should be rejected.

No second chance is given. There are no alternate methods. There are no shortcuts. The protocol's envelope was explicitly designed for evaluation in a simple sequence for security, and suspicion of the smallest deviation in a transmission is justified.

If valid to this point, then the header and footer can be stripped from the contents. Their parsing, validation, and authentication can proceed. If a required element does not meet specification, then the transmission is invalid and should be rejected. If any envelope element contains information, regardless of whether or not the recipient wants it, then that information must meet specifications for that element or the transmission is invalid and should be rejected.

That brings up another point. The real purpose of the first slot in the header was to assist the programmer by bypassing the illogical array numbering of most programming languages. If the header is programmatically split on element terminators, then the so-called "number zero" element can be ignored and discarded. However, if that "number zero" element contains anything, then the transmission is invalid and should be rejected. The resulting array numbers will match the logic of the human mind. (Do not split it until the character-by-character validation is done.)

But never split the transmission in its entirety. Never. And perform no other operation on the entire transmission until the initial character-by-character evaluation is performed as outlined above. The safest practice would be to remove the header and footer before doing anything with the contents.

Before proceeding to the contents, validate the entire header and the entire footer. They must meet the SysLink specifications in detail. If they do not, then the transmission is invalid and should be rejected. Any allowed deviation from any SysLink spec may defeat the protocol's security.

Identifiers can be a challenging subject for the system developer. Their nature is explicitly specified by the protocol, but validating their generation can be problematic. One might, therefore, be tempted to ignore them. However, if you give some thought to their function, you will find that they are an important part of the integrity of the communication, so the challenge is a worthy one.

The protocol precisely specifies the header slot contents. Any deviation makes the entire transmission suspect and it should be rejected. Descriptors are not permitted within the slots. If the date-time slot is used, then the CoreDate protocol is recommended in it because :
      It is self-describing, obviating need for other description.
      That feature also allows any precision without negotiation.
      It minimizes your programming and errors.
      It is easily red by both systems and people.
      It is always formatted for sorting that is logical.
      It increases SysLink universalization into future areas.

After validation against protocol specification is complete, the data in the header can be addressed as communicated information. For example, an authentication string can be evaluated against local requirements. If serial numbering is being used, the current number can be evaluated. A session number can be validated. Etc.

SysLink is expected to be used in hostile environments; part of its purpose is to overcome such environments. That may lead the developer and management to consider relaxing the protocol in some situations. But altering the protocol in any way will defeat its security. Furthermore, you will do nobody a favor by allowing protocol degradation, but strict discipline will help insure universal utility for the community.

Inter-system conversations within protocol are provided-for to assist with problems. Even those that accept public queries should maintain protocol for self-preservation and to support alien and disparate comm link needs. And pushing the neophyte system developer will be a favor to him and to the community.

If all envelope elements parse correctly, and are validated and authenticated, then they may be forwarded with the transmission contents to the next processing phase.

SysLink is designed to handle the complex and problematic communication interface as simply as possible. The above processing, if done in small steps, is not complex and it is the recommended minimum. It should always be performed by the receiving system as though that processing is, itself, part of the protocol. It will filter out much of the low-level "script kiddy" maliciousness, and it provides a foundation for mid to high-level security.

The Authentication Slot

Be careful.

Authentication can be sent within the contents of transmissions, but flexibility is needed for protocol universalization. For example, the respondents may want authentication before the contents are opened, so the last header slot is provided for authentication.

Because authentication is not controlled by protocol, it can contain anything that is permitted in the envelope header. Therefore, until your processing system inspects its content, it should assume that that slot contains malicious executable code. If it contains anything unexpected, then the transmission is invalid and should be rejected. If authentication is expected, and the contents do not produce a valid authentication, then the transmission is invalid and should be rejected.

A character string that looks like an authentication can easily hide malicious code. For example, an AxleBase authentication is easily red by a person, but that which is seen is not that which is being transmitted. Therefore, if the slot contains any character(s) when an authentication is not expected, then the transmission should be rejected. If the designer wants weaker security than that, then at minimum, the transmission should be quarantined until inspected by the administrator.

Location of authenticators should be addressed by management in the design phase. Consider implications of the previous paragraph. Should it be on the server, or the app, or both?

All Command and Control Strings (CCS) are precisely and unambiguously specified as literals. If a string does not precisely match a CCS, then it is not a CCS and should be ignored. If that disregard produces an invalid payload, content, or envelope, then the transmission is invalid and should be rejected.

Know the protocol release with which your system will comply. A character string that does not match a CCS within that release is not a CCS. Plan how your system will respond to each of the optional CCS. (No response is a response.)

Every CCS is defined as a literal and is specified in detail. Do not accept anything else as a CCS because it may compromise your installation's security.

If a CCS stack is present in the envelope contents, remove it before processing the contents. Then split it and validate.

The stacker CCS protocol is specified in such a way that using the stacker CCS as the delimiter to split a stacked payload will remove the stacker CCS and will produce a correctly numbered array of stacked elements. In other words, the stack element numbering will logically begin at one.

Not only does the stacker CCS separate the contents, it also delimits the stack. Therefore, depending on the language, the last element may be empty merely because a stacker CCS terminates the stack. Although protocol does not explicitly deny empty stack elements, any other empty element should cause suspicion.

After initial CCS stack parsing and validation, notice that they fit into the Visual Basic "select" construct and into the C++ "elseif" construct. The construction of a CCS "select" block or an "elseif" block at that point should simplify the logic thread routing for further processing.

Some CCS carry data as an appendix. The general approach to processing CCS that carry data is to first validate the CCS, which will tell you whether or not it may carry data. Then remove the first thirty characters, by count, from the appended data envelope.

A CCS data envelope consists of two characters, so remove the first character and the last character. Do not look for a certain character to remove, but remove the first character and the last character. The remainder is the data. After removal, verify that they are the correct delimiter characters. If not, then the transmission is invalid and should be rejected.

Some CCS data envelopes may be empty. But note that the protocol specifically provides no null character.

Contents of all of the envelope slots are specified. If the datetime sent slot contains a CoreDate, no descriptive text is needed in the slot. You will know that it is a date by its position in the header.

Be careful of the authentication slot. Characters in it are limited by protocol, but the size is not limited. If authentication is required, it should be evaluated as soon as possible in the processing stream.

The envelope content is not specified. That allows it to be any size that can be accommodated by the infrastructure technology in a transmission.

The header and footer contain multiple identifier strings. The protocol permits identifier strings to be shorter than the specified length if the source system has limitations. However :
      Seldom will today's systems have those limitations.
      Your communication security depends on those identifiers.
      Your system will be receiving unrecognized traffic.
Therefore, unless you have reason to do otherwise, you should require the specified length, and you should reject transmissions that do not meet it in all identifiers.

Identifiers are required to be strings of random characters. Specifically check for repeating sub-strings in identifiers. They can be an alarm that the source software is basing the identifiers on characteristics of the source. The protocol specifically disallows that practice because at least one manufacturer has demonstrated how it could use that to trace its software worldwide. If not stopped, it may compromise security, not only in the source, but in your system as well. If detected, then the transmission is invalid and should be rejected.

Look for strings of related characters in identifiers. For example, some may be tempted to embed dates and(or) times in them. Such a string violates protocol and the transmission should be rejected.

Look for identical identifiers. By definition, each identifier is a randomly generated string, so a duplicate identifier of sixty characters probably violates protocol and the transmission should be rejected.

Uniqueness Requirements :
      If you need to store traffic, as do big business and big shadow government that spy on American citizens, then you will need a unique identifier for each inbound message, but truly random strings can be expected to sometimes repeat. For uniqueness, first verify that randomness was attempted within identifiers. Then, have your system concatenate the identifier with other elements such as your session identifier to create an identifier for each message.

( Reminder :   Appendices are outside the protocol. )

Outbound traffic is easier to handle than is the inbound traffic because security is a bit easier to handle. The most important thing to remember is that SysLink may appear to be an easy-going affair, but it is in fact precisely stated. The recipient of your transmission will demand that your message meet specifications for his own safety.

There will be a temptation to relax standards with people and organizations that you know. If you do that, then the work on your processor will be wasted when you begin communicating with a different respondent. The protocol allows a relaxed interchange for those who desire such; just use only those parts that are required.

Argument for the boss:
      The cost of building a SysLink processor should be minimal and certainly no greater than helping a stranger debug and evaluate his. Also, having our own will allow us to maintain our own security. Also, programming is fun. So it is good for me and good for the organization if I build it for us.
      A bit of humor with a point. The protocol is so simple that a processor was built into AxleBase as an optional interface. It really should be built in house where programmers are available.

Before beginning, a detailed study of the protocol is needed. You will discover decisions that must be made before you begin design and construction. Perhaps your boss already has an organizational protocol implementation guide. If not, then you will need to make those decisions and, perhaps, document them for the boss. That will prepare you for the inevitable questions and will ease management's unease.

Much of the following reflects the programming methodology of only one man. It is intended to help the junior-level developer, and perhaps to help the senior level developer get started, but certainly should not be accepted as the best way.

Variables :
      Generate a named variable for each slot in the envelope header and footer. Include variables for the characters that separate the header and footer from the content.
      Note every variable that you will want to use.
      Create administrative variables for the :
          Header.
          Footer.
          Payload.
          Content.
          Message.

Payload :
      Receive the payload into its variable. If encryption has been specified for it, encrypt that variable.

Content :
      Move the payload with any required CCS into the content variable. If encryption has been specified for the content, encrypt that variable.

Date and Identifiers :
      Generate the date and identifiers. Move each into its variable.

Authentication :
      If authentication is needed, generate and move it into its variable.

Lengths :
      Insert a named placeholder in the header length variable. You will replace it later with the actual length value and the replacement must not change the length of that variable, so pad it with spaces if needed.
      ( The protocol does not preclude padding spaces. )
      Do a similar placeholder for the footer length.
      Measure the content and place that value in its variable.

Element Separators :
      Append the two-character separator to every variable.

Construct Header and Footer :
      Concatenate the header elements into the header variable.
      Concatenate the footer elements into the footer variable.
      Be sure to do it in the correct sequence.

Final Lengths :
      Measure the header length.
      Replace its placeholder in the header with that value.
      Measure the footer length.
      Replace its placeholder in the header with that value.

Assembly :
      Concatenate the header variable, the content variable, and the footer variable into the message variable.
      If required, encrypt the entire message variable.

The message will be the transmission. Deliver it to the transmitter process.

Your SysLink processor is done.

The intent is for SysLink to be universally transportable so that it can be used anywhere. Therefore, you can address your SysLink transmission as you would any other transmission, hand it to your local transmission system, and it will be transported. At the time of the creation of SysLink, nearly all communication uses the TCP/IP protocols for transport. If that is true for you, you will address your messages using the usual IP address or name.

If you are already transmitting messages, data, etc., you can use that transmission procedure for your new SysLink transmissions. If your organization has a SysLink server, you can enter the address or name in slot 22 of the header, and your server will send to that address.

The interesting thing about that feature is that it gives you the ability to use any other communication medium and transport protocol. If you would care to look at the Routing section, you will find that you can use complex addressing to send your message across a route consisting of many types of networks. That is what we call a heterogeneous network. Slot 22 of the message header is for that purpose.

Designing for errors is a large part of any system development. The SysLink developer and his manager must explicitly consider how errors will be handled in their system. The error handler must include :
      Local errors.
            Action response to local errors.
            Message generation by local errors.
      Inbound message errors.
            Action response to errors in received transmissions.
            Message generation by those errors.
      Complaints about outbound messages.
            Action response to received error messages.
            Responses to those messages.
Designing for those items will help you maintain the operational integrity of your system and the security of your organization.

Programming for communications can become confusing. Notice the construction of the above list that creates groups to help us monitor "who is doing what" so that we respond correctly. The list for a production system may be more extensive and may include more abstract control headings.

Remember that SysLink does not require reactions and responses to errors, which allows high levels of security. But reactions and responses are recommended whenever permitted by local security policies. Local personnel will decide when, whether, and how the system is to respond. If needed, the standard CCS error response is
          **syslink error notification**>specification<
Your system can also request a retransmission of the erroneous message with
          ** resend lost transmission **>specification<

All errors, regardless of source or cause, should be logged.

Any deviation from or non-compliance with protocol is an error.

The protocol requires the specification of the protocol release number that governs each message. That allows unattended systems to negotiate the governing release of a session before beginning the session, and if that fails, they can decline the session request.

The following are certainly SysLink protocol errors:
    001   A header without a footer.
    002   A footer without a header.
    003   The header is not properly constructed.
    004   The footer is not properly constructed.
    005   Envelope is empty.
    006   Header and footer message identifiers do not match.
    007   Invalid or unrecognized CCS.
    008   Transmission outside an open session.
    009   Other structure or CCS non-compliance.
    010   Other protocol non-compliance.
             (Superfluous closures are not errors.)

The following may be considered SysLink errors within the construct usage, but are not protocol errors:
    050   Invalid session number.
    051   Sender ID not registered in session.
    052   Requested release number not supported.

Caution! The Advanced Topics section is for highly experienced communication developers and their managers. Use by others can destroy security and create needless, dangerous, and expensive complexity.

( Reminder :   Appendices are outside the protocol. )

** Routing is entirely optional. **
It is a complex subject that should be ignored by most people.

Requirement :
      Routing is not required by SysLink; the old TCP/IP
          mechanisms can continue to do it as they have
          done for decades.
      SysLink routers are not required.
      However, advanced routing can be serviced only
          by SysLink routers.
      And advanced high-level security can be provided only
          by SysLink routers.

The optional slot 22 of the envelope header may contain a routing request. For security purposes, the recipient is not required to honor a routing request and is not required to respond to the requester. Furthermore, a router may be dedicated or filtered so that it services an exclusive set of sources.

Motility was not included in its conception, but it became obvious that SysLink objectives were bigger than the world of the TCP/IP stack. Existing technologies were not designed to allow messages to move across many different media and protocols, some of which had not even been invented yet, but that was what SysLink needed. That problem was alleviated by giving SysLink a means to specify routing that included, but was not confined to, the existing standards.

Routing, as used by SysLink, is the application of a state to the message by lower level protocols. For example, the string, address=68.136.86.118, is a request for spatial translation of the message to that address.

The routing details that are covered in this section are not part of the SysLink protocol at this time. As part of the Implementation Protocol Implementation Tutorial appendix, they are only suggestions for use of the header routing slot. Also, they are an investigation of that area of communications as possibly appropriate to and worthy of inclusion in the SysLink protocol.

As system design suggestions and computer science investigation, any of this section may be changed or discarded without warning, without comment, and without regard for existing implementation.

SysLink is a high level protocol that has little to do with moving information. Its primary purpose is to provide a universal and secure interface to the external world. The provision in the protocol for routing does not mean that your SysLink server must address data movement. Slot 22 is a routing request and not a routing directive.

SysLink routing does not contend with other technologies and especially not with the standard Unix TCP/IP stack. The purpose of SysLink routing is to :
      Increase flexibility.
      Allow unusual routing.
      Provide increased security.
      Encourage new technologies.
      Support very old communication technologies.
      Bridge between disparate communication technologies.

The TCP/IP protocol stack is robust and dependable, and civilization has a large investment in it, so replacing it is not recommended. It provides many important communication services. Before attempting to replace it, ensure that the new protocol(s) provide(s) the same features.

New technologies are now being developed to support new communication requirements. It is hoped that SysLink's flexibility will support them, so comments and suggestions are welcome.

Legacy SMTP Headers :
      Each legacy SMTP transmission accumulates a routing history header in-transit. Additionally, Big Business has made that header a trash pile of unsolicited advertisements and pseudo-security measures. Over half of some messages consist of the junk-filled header.
      A router or server may not do that to SysLink transmissions. The SysLink protocol requires that the entire transmission be the envelope; it allows only its own envelope header. A routing history header, or anything else added to a SysLink transmission, would be a fatal error for the transmission.

( NOTICE:   Content distribution (CDN), content centric (CCN), and information centric (ICN) network types are being designed to violate copyrights to steal intellectual property, so they will not be evaluated or considered because they are organized crime on a global scale that reflects moral decay caused by globalization of our affairs.  )

Some purposes of the SysLink routing slot :

SysLink Servers :
      Instead of adding a SysLink interface to every system, an organization can build a server that handles the entire external interface, performs all SysLink processing, and routes incoming traffic to the appropriate target. In that case, the routing slot can be used to target recipients in large organizations.

Large Geographic Dispersion :
      SysLink can be used to increase security and control of a large and geographically dispersed organization. All of the organization's traffic can be sent to a central proprietary system that opens the envelopes for the routing instructions, re-encrypts, and forwards.

Environment Interface :
      SysLink supports the use of any hardware, software, and protocols, so a SysLink server can become an interface between dissimilar communication environments. A SysLink router can receive a transmission from any source, analyze its routing request, and hand it off to the appropriate server. SysLink does not care if you route via optical fiber to a human courier to the destination.

Security Support :
      The routing slot may be used as a hidden address. In that case, the message is sent to a secure SysLink server that can send it to the hidden address; possibly via a more secure medium.

Extended Flexibility :
      Routing in SysLink is expected to enable and encourage research and development of totally new media and protocols, over which the SysLink community will then communicate.

An Address :
      A simple name or IP address, perhaps with a port, to allow the low level transport protocols to deliver it.
      Other protocols may use something different from, but conceptually similar to, the IP address, in the routing slot.

Routing Schema :
      Allows storing complex and hidden routes on the server that can be specified by passing messages in the routing slot. See the SysLink Routing Schemata sub-section.

String :
      A routing string may contain any combination of the other types. The string may contain or be composed of schema elements and features. (See the SysLink Routing Schemata sub-section.)

( SysLink routing schemata are not currently part of the SysLink protocol. The topic coverage is currently only a suggestion. It may be considered in the future for formal recognition as an extension to the protocol.
      For those wanting to implement simple SysLink systems, this complex subject, with its even more complex system and security requirements, may be entirely ignored without degradation of the protocol.)

Purpose Of Schemata :
      Provide unusual routing.
      Provide additional security.
      Decrease administration of complex routing.
      Make routing uniform.
      Encourage development of new technologies with
        new or unusual routing specifications and(or) syntax.

Suggested Usage:
      1. Individual requests.
            The specification of a SysLink schema in a message's routing slot will cause that schema's instructions to route the message.
      2. Domain application.
            A message domain specification in a schema will cause the application of that schema to all of those messages that fall within that domain description. (See the Domain topic header below.)

Insertion:
      In addition to local insertion,
      if the local server is given the ability to receive,
      and pursuant to local security compliance,
      then schemata may be remotely inserted into,
      and(or) removed from the server's files.
      (See the API Suggestions section.)

Naming Of Schemata:
      A schema will be locally uniquely named.
      The first character in a SysLink schema document is a left pointer(<). Following that is the name or identifier of the schema, which is closed by the right pointer(>). One or more spaces will follow it. Line breaks may follow the space.
      That name or identifier also identifies the schema file.
      That name or identifier is the schema handle for routing and for external processes. It may be obfuscated with lookup tables for security.

Schema Request:
      Valid schema requests apply the schema to the message.
      The schema request is verbose to support future needs. Slot 22 will contain the string

Timeout:
      A schema may contain a timeout.
      A CoreDate is recommended.
      Expiration requires destruction.

Domain:
      Domains are locally defined.
      Domain in this context is established by a descriptive analysis of the domain's message population.
      A schema may be identified with a domain by inclusion in it of a domain operative element.
      Domain schemata take precedence over requested routing. They will be applied by the server to all messages that fall within domain schemata's specifications. (Schemata and(or) local policy must specify what to do with overriden routing requests.)

Instructions:
      A schema contains operative elements that are name-value pairs that are routing instructions.
      Each instruction element contains a name followed by an equal sign followed by the value. The names are lower case. There are no spaces between the equal sign and the value in an element.
      Multiple values with comma separators are permitted in an instruction. The recipient of a PostalAddress element will treat each comma in the value as a carriage return / line feed.
      Elements are separated, delimited, by one or more spaces. Line breaks may be placed between elements for readability, but will not replace spaces.
      ( See the Routing Element Names sub-section for a list of suggested elements.)

Extended Paths:
      Slot 22 may contain multiple schemata.
      The server will attempt to satisfy only the first schema.
      A schema may contain an extended path.
      The unexecuted portion will be inserted into slot 22.
      The resulting path validity is the sender's responsibility.
      That insertion must conform to SysLink requirements.

Brackets:
      Where indicated, parts of a schema are enclosed in left and right pointers. They are ASCII characters 60 and 62 that are < and > on the American keyboard.

Separators:
      Where processing or routing requires logical grouping, separators may group elements. The separator is

Hierarchical Constructs:
      Hierarchies may be constructed parenthetically. Examples using it in a request for reverse route response:
reverseroute=(protocol=tcp/ip address=42.280.56.233)
reverseroute=(schema=283 schema=1157
              (address=42.280.56.233 port=200))
      Superfluous parentheses are not erroneous, and may, for example, be used to insure the processing integrity of a value that must contain a space.

Comments:
      A schema may contain comments.
      Comments are ignored by the processor.
      A comment block is identified by a header and a footer string.
      The header and footer are literal in lower case, with no spaces, and with a space on each side of the literal string.
      The header string is

Line Breaks:
      Line breaks with carriage returns are permitted in schemata for readability. However, unprintable characters, and specifically line break codes, are not allowed in envelope headers. Therefore, if a schema or any part of it is copied into slot 22, any line breaks in it must be removed.

This list contains suggested names for routing instructions. It is not intended to be exhaustive at this time. See the SysLink Routing Schemata sub-section for usage. Mixed case is only for readability, and is not required.

Slot 22 usage begins at the source. The user may decide how he wants his transmission routed, such as by entering the mailing address of a correspondent. He may do that through a software interface such as mail client software, or he might type it directly into an envelope header in notepad, and pass it to a local SysLink server. It is possible that addresses might be entered by local management policy as expressed in an automated server.

Coming from the originator, or source, slot 22 may be :
      Empty
      A simple name or address.
      Or an extended complex routing string.

Although detailed routing from the source is possible, it is not necessarily recommended. Anybody entering a route in slot 22 must be aware of the potential complexity of SysLink routes, which can far exceed that of TCP/IP. For example, it is possible for the next element in a route to be a telephone number in Missouri after arriving on a router in Siberia, which could be problematic. It is usually better to enter the destination and allow intermediate servers to use their tables to route as needed.

( The complexity-potential in SysLink routes is by intent, and you will note that it provides extended communication features for the protocol that cannot be done by other protocols. It is possible that the simple fact of complexity may be addressed for reduction in the future, but that is doubtful because it can be handled by local management and administration where needed.)

SysLink routing has opened vast new fields, so server developers should be aware that the sender may have a legitimate reason for specifying a detailed route of which the server may not be aware. He might, for example, be routing entirely within a secure medium inside a national border, or confining the route to a cruise ship's LAN, or perhaps using high security across the internet (See the Routing For Security and Encapsulation sections.)

Although not recommended due to their complexity, any of the mechanisms presented for the router in previous sub-sections may be used by the originator. All of the SysLink protocol restrictions and constraints must be observed.

Route Execution :
      Ignore this subject. It is currently a placeholder.
      This subject is under consideration.

Under consideration and(or) construction.

Comments will be considered with appreciation.

A function similar to TraceRoute and PathPing is being considered to support SysLink routing. It must have little or no impact on existing SysLink specifications.

Implementation might be in a CCS, but a CCS might cause confusion because routing is outside protocol, which would produce a non-canonical CCS. Fortunately, the protocol does not preclude non-canonical CCS, but the possibility of confusion cannot be ignored.

A succinct CCS traceroute would have little impact on speed, but requiring the router to inspect the contents of every transmission for the presence of that CCS could slow traffic tremendously.

Every router must inspect every message's slot 22 for instructions, so adding a traceroute request in that slot would induce minimal delay. However, it would add to the complexity of handling that slot.

Responding :
      At inception, it appears that the return must be built
          within the body of a returned message.
      Each responder would add its data.
      Would that violate the sanctity of SysLink messages?
          The responders would be building new messages.
      Should a server-return CCS be used for the return?

Security :
      Some paths will include secure routers. A response by a secure system would compromise its security, so routers cannot be required to fully participate, or to participate at all.
      If a secure server elects to respond, but will not participate in the entire response, it can leave values blank. It should list all elements with equal signs and commas.
      Some consumers will use secure paths that use only secure routers.

Incentives :
      Participation might be encouraged by including the ability to name the router's manufacturer in its return. (The computer on which a server runs is only the computer; it is not the router.)

( Let us take a moment to reiterate this fact to avoid confusion among neophytes. The computer on which a server runs is only the computer; it is not the server. The writer notes that, in this very document, he also is guilty of lapsing into incorrect usage although he has, himself, built a beautiful database server.)

Response Construct :
      Responses will be in standard server envelopes .
      The server envelope will be in a SysLink message.
      The response slot will identify the requesting message.
      The rubric slot will contain the ping type in lower case.
      Response can contain only printable characters.
      The response consists of elements.
      Each element is optional for security.
      Each element is a name-value pair.
      Each element is terminated by a comma.
      Response cannot contain other commas.
      The requestor can split on commas.
      Element names must be lower case.
      Name and value are separated by an equal sign.
      Will have a maximum character count for each element.
      Elements :
          response=ping (Must be first element.)
          hop_duration (Use prior time in header.)
          Infrastructure :
            server_type (router, bridge, gateway, database server...)
            server_name
            server_address
            server_version
            server_build
            server_manufacturer
            computer_manufacturer
            computer_model
            computer_build_date
            operating_system_name
            operating_system_version
            operating_system_build
          prior_node_name
          prior_node_address
          prior_node_type
          prior_transport_medium (cable, fiber, etc.)
          prior_transport_protocol
          next_node_name
          next_node_address
          next_node_type
          next_transport_medium (cable, fiber, etc.)
          next_transport_protocol
Prior and next nodes may be needed if those are SLED systems (SysLink-deficient) that cannot participate.

Query Types :
      ping
          The last server will respond minimally.
      ping_verbose
          The last server will give a complete response.
      ping_path
          All servers in the path will respond minimally.
      ping_path_verbose
          All servers in the path will give a complete response.

The function is for SysLink routing. Any server is free to insert legacy SLeD (SysLink-deficient) routers such as a TCP/IP server or phone switch in the path and that inserted node could not participate. The same caveat applies to SLeD destinations and dumb terminals. Those legacy systems would lose the request.

The standard SysLink error handling is applicable to all routing errors. Included are :
      Erroneous requests.
      Inability to comply.
      Execution errors.

( The error reports are being evaluated in hopes of expanding their ability without expanding complexity. See the CCS routing error proposal, and proposal 24 in the Upgrade Proposals section of Administrative Text. )

If a dedicated CCS is not implemented:
      It is recommended that the error description begin with the literal "routing".:
      If the error is in the request, then the second and third words should be the literal "request error".

If the responding system can determine an erroneous element in the requested path, then that element should be specified. Otherwise, the entire path should be returned in the error description.

If the target system cannot be found or reached, and the request is not certainly erroneous, then the recommended return is a more ambiguous "routing specified path cannot be serviced" with the path.

FaultDelay Request:
      (See instructions for element pair usage.)
      The faultDelay element pair is a request for the router to hold the message for delivery after the failed route comes back on line.
      If a value is specified, it specifies whole seconds. The message may be saved up to that number of seconds or until the route is restored, whichever happens first.
      If the router cannot, or will not, comply with the request during an outage, then an appropriate error response will be returned.
      If the outage exceeds the requested value, then an appropriate error response will be returned before destroying the message.

Requirement :
      Routing is not required by SysLink; the old TCP/IP
          mechanisms can continue to do it as they have
          done for decades.
      SysLink routers are not required.
      However, advanced routing can be serviced only
          by SysLink routers.
      Also, advanced high-level security can be provided only
          by SysLink routers.

SysLink is designed with a great deal of technology neutrality, allowing a SysLink server to be used to create heterogeneous networks. The SysLink server can become a bridge between dissimilar communication technologies, and may encourage specialized communication technologies.

Where dissimilar communication technologies are expected to work together, each will be provided with its own end-point. That end-point is known as a terminal because it terminates a network, or as a gateway because it is a gateway into that network. Let us use the "terminal" word in this brief discussion, but either may be used in these appendices due to editorial shortcomings.

If your server is an interface between media and(or) transport protocols, then SysLink terminals for those networks will be provided and your router/server will be given access to them. Your server will hand a processed transmission to a terminal for retransmission. You or a co-worker must design the local communication architecture that addresses system interface issues. One of the beauties of this technology is its flexible implementation of solutions. Many features might be invented and created in the communication architecture for an intersection of networks.

Remember that SysLink can be implemented in all environments, so local terminals of many technologies can receive a SysLink transmission from your server. The message must be appropriately addressed for that environment, or it must contain an appropriate routing request in slot 22.

An easily understood example of a terminal might be for courier or hand-delivery requests. That terminal might simply be a printer or a removable disk drive in an office. For a few more examples with interface comments, see the Unusual Or Miscellaneous Technologies section later in this appendix.

The most common terminal is a router for the TCP /IP /ethernet protocol stack, and its medium is usually a catV cable. The link to that router will be a network socket server on your server's computer. Your server will hand the processed message to that socket software, which will send it to the network router. Your processor addressed the message, so the router will forward it to that address.

Your server may access other terminals in the same manner over the network. Their requirements will vary. Some may be on a public or crackable network that requires that you deliver a complete SysLink envelope to them, or they may be secure and need only the payload with an address. Like the TCP-IP-ethernet router, they will forward the message via their protocols on their media.

Bridged heterogeneous networks may become difficult to manage. For systems that will take advantage of such bridges, the Routing Schemata sub-section has suggested element names that may be beneficial. For example, the reverseroute or the returnroute might be used to specify a complete return route that the recipient could extract and plug into the return envelope. Control and formatting instructions allow a return address to be sent with a forward address.

The comm check CCS is designed for use across heterogeneous networks. It can be used to check the status of a session link across any topology. It can also be used to determine absolute duration across any heterogeneous network topology.

All who use or service SysLink communications should be generally aware of the extreme diversity potential in a healthy SysLink network because that diversity is intentionally encouraged. As an extreme example, a route that includes an interplanetary segment will exhibit an inordinately slow response that might disrupt operations if the sender is not prepared for that segment.

Judging by Man's current directions and expressed communication needs, some future transport protocols and media may be very different from our familiar TCP/IP over copper and optical fiber. In any case, bridges and terminals are expected to be generally similar to that outlined in this section.

We are acquiring tools to support SysLink routers. For example, the AxleBase* database manager has demonstrated lookups within seconds from a hundred-billion row table and sub-second returns from smaller tables, all on commodity desktop computers. Those that were large routing tables of the past are tiny for AxleBase. Since it is designed with a documented API to be embedded in other systems, AxleBase can be built into the above applications.

( AxleBase*)

( NOTICE:   Content distribution (CDN), content centric (CCN), and information centric (ICN) network types are being designed to violate copyrights to steal intellectual property, so they will not be evaluated or considered because they are organized crime on a global scale that reflects moral decay caused by globalization of our affairs.  )

Requirement :
      Routing is not required by SysLink; the old TCP/IP
          mechanisms can continue to do it as they have
          done for decades.
      SysLink routers are not required.
      However, advanced routing can be serviced only
          by SysLink routers.
      Also, advanced high-level security can be provided only
          by SysLink routers.

Stand-alone private networks, such as sensor networks, can be terminated and bridged as previously described. Such a topology permits the creation and use of specialized technology that may be needed in that particular network such as operating systems, communication protocols, etc.. The SysLink bridge can safely express the entire sensor network as a single node that uses standard technology in a master network, public network, or internet network.

With the bridge, the feeder network will probably have its own terminal to provide management granularity. The isolation thereby provided by the SysLink technology also allows the bridge and terminal to function as a secure gateway into the private network if needed. A truly private network would be an isolated management object that is physically insulated from public problems with access only through its gateway.

More complex network requirements can be met by the creation of hierarchical network constructs in which each independent network level is expressed by its bridge as a node in a higher level.

This may require an elementary understanding of databases and database manager operations as well as of communications.

The use of a feeder network with its terminator would allow the inclusion of a database server in the terminator to harvest data, accumulating it until a trigger or message unloads it to the bridge for retransmission on the public network. The AxleBase* database manager is actually designed to be embedded within software systems.

An overwhelming data stream harvest can cause data loss through concurrency conflicts. The AxleBase torrent technology can help with the management of heavy data streams. A DBA (Database Administrator) participating in network design and implementation can turn on the needed features and configure database managers for support.

AxleBase can run on commodity desktop processors to reduce cost if needed. Proprietary internal AxleBase algorithms deliver very high speed on desktop processors. (See published tests on the AxleBase* performance document.)

AxleBase is a powerful database manager, but is miniature despite his power, occupying less than one megabyte of disk space. Thus, he might be deployed remotely in minimal hardware with networks that he serves.

Where sensitive data is being harvested, AxleBase offers advanced security options.

(See the mobility support section for additional discussion.)

( AxleBase*)

( NOTICE:   Content distribution (CDN), content centric (CCN), and information centric (ICN) network types are being designed to violate copyrights to steal intellectual property, so they will not be evaluated or considered because they are organized crime on a global scale that reflects moral decay caused by globalization of our affairs.  )

( Reminder :   Appendices are outside the protocol. )

Let us take nothing for granted in matters of security except our own failures and the evil in Mankind. Those are assured.

1.   The internet is a hostile environment of malevolence.

2.   You slavishly connected your life to that environment.

3.   Your home computer is under attack or external control.

4.   Your business system is under attack or external control.

5.   Your so-called cloud is under attack or external control.

6.   The radio that you call a phone is open to the world.

7.   Massive losses are being sustained by big business and government that the deceivers hide from you while you pay.

          Those statements are without qualification.

This is a new age of piracy, rape, and theft by sociopaths and psychopaths. In matters of security, there is no discernible difference between the conduct of criminals, your government, and big business, including their rationalization of their behavior and their contempt for you.

A government that spies on its own law-abiding citizens and has historically promoted the wholesale export of our technologies looks ludicrous when it complains that we protect ourselves from its spies and other enemies.

Publication of the SysLink protocol in detail has made it public, thereby making sophisticated counter-measures against it expected. But rigorous publication is expected to increase its effectiveness due to its foundation design at the theoretical level, if the protocol is rigorously followed.

This Security section is recommended neither for beginners nor for those who have limited resources because security theory and its implementation can become complex. Some of the contents are far more complex than is apparent.

It is important to remember that SysLink is part of intelligent management, and does not stand alone. If advanced SysLink security is implemented while the office is left unlocked every night, all will fail.

The popular, ludicrous, and criminally misleading term "firewall" is not used in this document.

Although not its only objective, the SysLink protocol was designed in support of the generalized concept called "security". That approach delivers a foundation and framework to support massive security structures, and permits great flexibility beyond the SysLink designer's abilities, thus allowing implementers to design security to meet local needs.

The security ratchet concept is offered to ease planning and to remind the planners that a level of security should be identified and explicitly stated. Planning can then proceed to affect that level of security.

Local implementation allows implementers to ratchet to a needed level of security with its concomitant level of complexity. At the bottom, the protocol allows use without any security. At the top, the designer can pick and choose from the strongest security mechanisms. Any amount between those extremes may be used, and levels may be mixed.

In this section are ideas that may be used and altered as needed. Many can be used together to increase security. They are entirely independent of the security measures of external protocols and systems. They are not intended to be exhaustive; some ideas having been intentionally excluded from publication. Mentioned ideas are intended to spark creative SysLink implementation.

Some security issues that arose after the computer revolution were laughable because they were caused by simple inaccessibility that is designed into complex systems. Those who own systems cannot control them, partly because they cannot see inside them. Evil men have simply exploited that fact. After all their interface rhetoric, computer developers failed to recognize that flaw in their human-machine interface, and even they sometimes exploited it.

In recognition of that problem, an important thrust of SysLink's design was to make the comm. interface easily accessible to the system's manager or owner and to enforce that accessibility. We do not need to see inside our vehicle's engine, but we demand to see and control items that are conveyed by it. That common sense was applied to SysLink design to bring that level of control to our computer systems.

Another objective was to make SysLink usable by unattended autonomous systems, and despite the temptation to abbreviate it for unattended systems, accessibility was maintained. An administrator can easily monitor the comm stream or analyze a malicious attack because it is in common American English.

The rigid enforcement of the protocol is strongly recommended to maintain easy accessibility. Beware of obtaining a SysLink server from outside your organization because you will not know what that system is doing. An example was the world discovering that word processors were hiding user and machine identification in documents that they created.

Appendix
Protocol Implementation Tutorial
Chapter
Advanced Topics
Section
Security
Sub-Section
System Interfaces



Address : jragan.com/syslink.htm#A7.20.25
-- . --

Interface Location

The protocol design provides enough flexibility to allow it to be built into servers, routers, and stand-alone local system interfaces. One of the AxleBase interfaces to its host uses SysLink.

System Interfaces

The protocol is designed for autonomic system operation. That feature was demonstrated in the feasibility study as described in the Feasibility Study section. The study placed the protocol in an interface of a high-end database manager that allowed remote database queries with subsequent data returns so that the protocol secured the interface and the in-transit exchange.

Consider including in the inbound interface to your SysLink server a mandatory delivery to disk, preferably an external disk. It is an old-fashioned departure from today's total in-ram software-to-software exchange and it will slow communication, but it enforces a distinct and dramatic interface that may give your server positive control down at the byte level.

Multiple Sources

Consider opening multiple ports on the server's computer. Publish the secure port to secure respondents and the server will require all inbound traffic on that port to be encrypted. The other port will be treated as unsecured. Multiple NIC IP's would be even better.

Multiple Secured Sources

Consider sharing a unique encryption algorithm with each secure source to encrypt all envelopes. Perhaps you could design your server to loop through each message a specified number of times with error traps until it gets a good decryption or exhausts all algorithms.

Or multi-level encryption could be used (see following subjects). The envelope could receive general encryption, and each source could apply its unique encryption to the contents. Upon receipt, the envelope could be decrypted revealing the encryption slot, which would tell which code to use to decrypt the contents.

Appendix
Protocol Implementation Tutorial
Chapter
Advanced Topics
Section
Security
Sub-Section
Encryption



Address : jragan.com/syslink.htm#A7.20.30
-- . --

General public traffic will not be encrypted. If encryption and(or) compression is used, it will be negotiated and agreed upon by management before communication begins. Therefore, you will know beforehand how to treat inbound messages.

The encryption option is available in multiple levels to support local independent encryption authorities. One or more of three levels may be independently encrypted in any combination ;
      entire transmission,
      the contents,
      and the payload.
Each of the upper encryption levels always re-encrypts the level(s) beneath it. (The Feasibility Study used all three levels.) This is known to some as an encryption stack.

The specification allows no expressed characteristics in an entirely encrypted transmission. When an envelope is encrypted, nothing can be known about the transmission. ( Except what might be learned from lower level transport protocols, and even that is addressed elsewhere in this appendix.) If your organization sends any sensitive information in the envelope header, then the entire envelope transmission should be encrypted.

The top encryption level, the entire transmission, is your server's responsibility. If that level is to be encrypted, then decrypt every inbound transmission before doing anything else with it. Again, do absolutely nothing to it until after it is successfully run through the decryptor. If it is not recognizable after decryption, then the transmission is invalid and should be rejected. If the decryption fails or causes anomalous behavior in the decryptor, then the transmission is invalid and should be rejected.

Responsibility for the lower levels may or may not be assigned to you (your system). The contents may always be encrypted or may be encrypted only when the header's encryption flag is set. The encryption flag is set (turned on) by the presence of any value. The encryption flag is designed so that it can, optionally, convey information about the encryption in addition to being a toggle. If no other information is conveyed, then it is simply a boolean toggle.

If the content and(or) the payload is encrypted, then do nothing to it at this point. Validate and parse the envelope as outlined in the Processing Inbound Traffic section. If it passes that operation, then extract and decrypt the content.

The SysLink design enables secure traffic inside an organization. If the addressee will decrypt the contents, then he must be warned of dangers outlined in the Processing Inbound Traffic section.

The AxleBase decryptor can perform its operation on all 256 of the ASCII character set, and can do it without executing malicious code. If possible, those two features should be required of any decryptor used in this operation.

A communication path across all types of networks and operating systems is problematic because each may handle a data character differently. Furthermore, some cannot recognize control characters or control methods of others, even within the same manufacturer.

Because some systems cannot guarantee the valid transmission of the entire character set across that path, they encrypt using only a subset of those characters, which is valid and possibly adequate. But even if expecting subset transmissions, your decryptor should meet the AxleBase standard to avoid anomalous behavior caused by the unexpected receipt of extended characters. If it cannot meet that standard, then it should be able to recognize a character that it cannot process, react appropriately, and notify the administrator.

SysLink intentionally requires you to provide your own
      encryptor,
      compressor,
      and authenticator.
That requirement gives you the freedom to choose, and thereby increases SysLink security.

Do not be bashful about building your own because, in case you have not been paying attention,
      - those that are open source have been cracked because they
          are open source,
      - the commercial systems have been cracked because that
          game is how the vendors get to keep selling "upgrades"
          to you,
      - government help cannot be trusted,
      - and none of those will tell you about the latest cracks. Therefore, your encryptor, compressor, and authenticator will be as good as any because you have a well-paid in house developer whom you did not out-source or off-shore.

The routing request in the envelope header can increase security by obscuring path, source, or destination from all except the SysLink system. The key is in the interruption of conveyance. A SysLink interruption of an in-transit transmission with a subsequent return to the TCP/IP protocols will obscure the source and prior part of the path. Routing it to a different medium or protocol can obscure additional information.

An organizational SysLink server interface with routing can entirely mask the internals of the organization. On a battlefield, the wise general deploys his mercurial cavalry to screen his operations, and uses movement to confuse the enemy. For extremely heavy security, consider the Terminals sub-section of the Routing section to help control quickly changed externally perceived organizational attributes.

See the Routing section and the Encapsulation sub-section for broader discussion.

Due to its complexity at the conceptual level and due to extended system development and management at the practical level, this technique is not recommended. It can be of great benefit, but only to those who need extreme communication security.

When used in unison, four SysLink features combine to ratchet to a higher level of security. Those features are:
      - The nature and character of the payload is specifically and
          intentionally not addressed by the SysLink protocol.
      - Payload encryption is permitted without consideration of
          the envelope and its contents.
      - The envelope, including its contents, may be encrypted.
      - SysLink routing overlays the routing of lower protocols.

To accomplish the encapsulation technique :
      Prepare a transmission envelope with its payload.
      Enter a routing request in the envelope header.
      Encrypt the entire envelope.
      Insert it as the payload in another envelope.
      In the encapsulating envelope, include the peel
        command at the appropriate point in its routing
        string or routing schema.
      Encrypt the encapsulating envelope
      Repeat as needed.
      Transmit.

The recipient server must
      be prepared for encrypted traffic,
      be routing-capable,
      be able to execute the peel command,
      and be designed to not reject a revealed envelope.
When that server encounters peel as a current request in a routing request, it will
      remove the envelope,
      decrypt the payload,
      read the new routing request,
      re-encrypt,
      and forward the revealed envelope.

This procedure will accomplish extreme masking, so participating systems must include reverse routing with the routing if a response is required. See the Routing section for reverse routing.

Hierarchical Encapsulation

Hierarchical encapsulation is done by multiple sequential servers. Each server that receives the transmission re-encapsulates the transmission so that multiple layers surround the payload. Each server is entirely responsible for insuring correct downstream handling including routing, peeling, and reverse routing instructions.

If the extreme of hierarchical encapsulation is necessary, then each encapsulator should, ideally, use a unique encryption algorithm. Where only one algorithm is available, they should, at least, use unique encryption keys.

Note that this technique can be used by multiple cooperating independent agencies at multiple points in transit to cloak communications, thereby affecting the extreme "need to know" security.

Bundling

The protocol design includes an absence of payload magnitude control. That feature allows the creation of servers that bundle multiple clients to combine multiple transmissions into a single capsule for heavily trafficked communication paths, thereby delivering additional obfuscation of organization characteristics.

Caveat

The complexity of encapsulation can also create additional security problems. For example, the processing design must account for attempts to hide malicious content in capsules. Therefore, those who use this technique must be thoroughly familiar with the protocol and rigorously enforce both it and local requirements.

These points are in addition to those that are covered elsewhere in this appendix. Make a considered study of the envelope because it is designed for security support. Some optional features can be employed in various ways.

Rubric Specification

As the name suggests, the header's Rubric slot specifies the nature, "raison d'etre", of the transmission. It might, for example, be the target organization's purchase order number for the enclosed invoice, which is going to the accounting department. That purchase order number might contain a milspec number, which would further route it within accounting.

Requiring the specification of an activity in the header's rubric slot could stop transmissions that do not provide codes that fall within the local organization's purview. If they pass through, then internal targeted systems can verify in detail that the codes are rational within their processing domain. Internal bulkhead servers might also use the rubric spec. to control internal movement.

Response Identifier

The header's response identifier contains the message identifier to which a message is responding. A very secure site can require that all inbound traffic be responses to requests from within. Those that are not will be stopped by your server at the external port.

One technique would be for your server to record outbound transmissions to identify valid responses. You could additionally record the time of the outbound messages and keep the list purged through timeouts. Finally, your list could include the IP address of the outbound sender to insure that inbound messages are addressed only to the outbound senders. A possible simplification would be to have your server enter identification in each message header. (Be careful of re-routing in the header slot.)

( The SysLink protocol precisely defines the term "identifier" and specifies its required usage. )

Source Identification

The word "identification" is here used in the broader context that includes more than the SysLink identifier. Notice that the source can be completely identified in the envelope header. That allows the entire transmission to be encrypted and totally obfuscated while in transit. The header will tell the respondent how to respond to the transmission. (See also the Encryption sub-section and the Encapsulation sub-section.)

( The SysLink protocol precisely defines the term "identifier" and specifies its required usage. )

Session Control

A communication session must be opened before communication can begin. The control of a session, as defined by protocol, is another of those areas where SysLink provides a basic structure, and then allows design for local requirements. SysLink does not use connections; the session is analogous to a connection, but only on a conceptual level.

The manner of controlling sessions should be addressed at both the organization level and the system level. Will you allow remote systems to request sessions? Will you allow remote systems to assign session identifiers? If your organization will assign identifiers, will it be done by the system or by the SysLink server?

Notice that ownership of a session is always unique to identifiable systems. Therefore, your server can identify each session with those systems as the session is established, and can then deny passage of transmissions that have mismatched or unmatched session numbers.

The header allows transmissions / envelopes to be serial-numbered within each session, and that is recommended for secure sessions. Anomalous number behavior should cause a local server to react. That serialization also permits synchronous communication.

Session state can be monitored and controlled by your system. Regardless of your security level, a system that tries to communicate with your system or organization without an open session has evinced aberrant behavior, and should be assumed to be malicious.

Systems and servers may simultaneously serve multiple SysLink sessions. If your system serves many systems, an open session list may be maintained. Systems and servers can require that inbound envelope headers contain a valid session identifier with sender identification.

Protocol requires that every session be formally closed. Always. Closure invalidates the session identifier.

Parsing And Evaluation

Security is a major factor in the foundation design of the entire protocol. Receipt and handling of a transmission should be done as outlined in the Processing Inbound Traffic section. Deviation from those suggestions may compromise the foundation security design.

SysLink is designed to allow direct comm links between external and internal systems if you so desire. They can administer their own SysLink comm. sessions without an intervening SysLink server. Before allowing that, consider your network architecture and security configuration.

CCS Payloads

Certain CCS carry their own functional payloads for which SysLink intentionally has minimal specifications. Your systems should never assume that a payload contains the expected. For example, an initialization payload could contain malicious instructions to the target system.

Either your SysLink server or the target system should parse, validate, and screen CCS traffic as does a database manager.

Error Handling

The SysLink protocol provides for error handling, but it does not require an error return even during a mutually recognized session. The developer and his managers can design an appropriate system error handler. If it is a hardened system that explicitly will return nothing, then it should be explicitly designed as such.

Discovery

SysLink does not require discovery participation and requires no response of any kind. Participation in discovery, such as service discovery, is supported if local management wishes.

Logging

( Please do not feel offended. The logging suggestion is intended only for beginning developers and their managers. )

A SysLink server should be built with internal logging because it >will< be attacked. Design your system to manage its log without your intervention, and remember that even the logging feature will become a point of attack. >Never<, design a log in such a way that it can "fill up". If the log becomes dysfunctional in any way, including filling up, your server must cease operation and report the problem. Log management is part of a server's duties.

Outbound Screen

Your personal and proprietary information is being transmitted to strangers, competitors, enemies, and government controllers as you read this. You may claim ignorance because of the way that it was accomplished. For example, at least one operating system was intentionally designed to send your information to its manufacturer at regular intervals and(or) on certain events without you knowing it. And even if you knew it, turning off all of the transmissions was difficult.

An outbound SysLink server screen can screen all outbound traffic to investigate espionage against you. Simply requiring SysLink protocol compliance will stop the older malicious systems. The newer ones can be caught by inspecting the message header for your required information.

A means of identifying valid outbound messages may be needed. If that identification is a code in the header, the server should remove it before it is passed into the external environment.

It is important that stopped messages be logged and that the log be inspected periodically. The log is needed even if the server immediately notifies personnel of problems.

Internal Bulkheads

Internal SysLink bulkheads can be established to control internal movement. They may be especially useful for large organizations that require exceptional security. They can control movement between departments and can verify that incoming traffic has authorized business in the bulkhead's section.

Such bulkheads could have stopped the massively successful attack on Target Stores that stole information belonging to millions of customers. That attack succeeded because it was routed through a trusted vendor, Fazio Mechanical Services, who's rubric could have been confined to authorized areas by internal SysLink server bulkheads. ( Keren Elazari, Scientific American, April 2015, p. 67)

Protocol Enforcement

The developer and his managers must decide upon the degree to which they will enforce the protocol. The most secure response, and the recommended response, to a transmission that is outside of, or that deviates from protocol, is nothing, which is permitted within protocol.

The protocol is specific, and any deviation from it creates security risks. For that purpose, within the protocol are the overt means of enforcing compliance that is expected of legitimate participants.

If you are offering a service that may be sought by many, and you want to respond to an error, perhaps you might attempt to open a SysLink session with the sender for the purpose of demanding protocol compliance. Just sending a SysLink transmission should be enough to alert the foreign system to the requirement. But, again, designing your system to take that action could compromise your security.

Link Status

SysLink specifies that any amount of time may lapse between transmissions for comm link endurance in hostile environments. However, an organization should address the timeout issue to set and enforce its own values even if they become defaulted to the SysLink value. Actions should be decided upon for timeouts.

Checking Links: SysLink provides the comm-check CCS for checking the status of a comm link, even across heterogeneous networks. It can be used to check for apparent timeouts.

Speed Determination: The comm check CCS can also be used to determine speed across heterogeneous networks.

( The VPN application was probably obvious long before you reached this point, and hopefully, was intellectually stimulating.)

The designer wanted strong security for AxleBase that could be administered by the AxleBase DBA (database administrator); that could make AxleBase safe even from inside attack. Based upon the history of security, the designer was distrustful of existing security. And considering the silly "cat and mouse" games that software vendors played with the criminals, there would be little or no improvement in the foreseeable future. It seemed that the only way to secure the AxleBase operation would be to develop a protocol for software that would be entirely controlled by the end user, which eventually resulted in SysLink.

So SysLink began as an effort to build a personal VPN; one that would be entirely controlled by and open to the end user. Thus, AxleBase became the first database manager in the world to have a built-in VPN.

And that is it. The protocol that you have been studying, and the implementation guidance that you have red in this appendix have presented a "how to" for building a VPN. You, the implementer, will decide whether or not it will be as secure as the expensive commercially available VPNs. Or possibly more secure.

Unlike other VPNs, SysLink simplifies implementation by ignoring low-level protocols and the operating system. Everything that is needed is inside the SysLink protocol.

Encryption, compression, and authentication are also intentionally ignored. That may cause problems for the timid, but it releases you from the control and manipulation of the marketers and increases your security. You can build or buy any encryption, compression, and authentication packages that you want and couple them with your SysLink VPN. (Hint: If you build your own, then share your software only with respondents or keep it entirely in-house to make life harder for the Homeland Security spies.)

TCP/IP provides the transportation and does a good job. SysLink provides the VPN and asks for no special configuration in the TCP/IP and operating system layers. You may find the freedom from configuring PPP, PPTP, L2F, L2TP, etc., etc. exhilarating.

Transportation should be simple after you surpass the fear. For example, most operating systems have the UNIX system's FTP, so perhaps make a simple dialup connection to an ISP, and then use the FTP PUT to deliver SysLink transmissions. PUT can place your file directly on the remote computer's disk drive. You cannot get much simpler, and this writer found that automating FTP for a contract client with a favorite language is very easy. But that is only one example; a SysLink design objective was transmission by any means.

( Reminder :   Appendices are outside the protocol. )

The purpose of this section is to provide dependable and secure communication support for a miracle of the twentieth century, massive numbers of communicators that are independently spatially mobile.

Mobility in this document includes wireless phones and other communication devices that allow spatial mobility. A cell phone can query servers as easily as can a computer and, thanks to SysLink, can communicate with all systems. (Please forgive this statement, but conference announcements indicate that many are missing this fact, perhaps because they forget that a cell phone is a networked mobile radio transceiver, by definition.)

SysLink Mobility Element:
      To identify systems that are spatially or geographically transient, the routing element "mobile=yes" may be inserted into slot 22 of the envelope header. When that element is encountered, respondents such as AxleBase will treat the session accordingly. Make that element the last in the outbound routing string so that it will be received by the target.

Timeout:
      The mobile app developer may take advantage of SysLink's timeout handling to create flexible apps. Adjust the timeout to fit the expected environment.

Synchronicity:
      The mobile app developer should make a conscious decision about how to handle synchronicity in his app. TCP can handle lost portions of transmissions, but the flexibility of SysLink creates an environment for the app that may increase the problem. For example, TCP is not designed for the vast heterogeneous network mixes that SysLink supports.
      In that case, SysLink's session identification with envelope serial numbering might provide a means to establish, validate, and support synchronous communications. That would allow a session or conversation to span many communication breaks and changes of low level protocols and media without disruption.

Server Discovery:
      A specific SysLink CCS is devoted to querying other systems for information including their server type and status.
              ** information return query **><
Additionally, an explicit categorical query for that particular CCS formalizes and eases server discovery. See the canonical categorical request in the query CCS.
The return will be in the query return CCS and will resemble:
          ** information query return **>**service forwarding**<
( See also the Categorical Response Guidelines section. )

This sub-section may require an elementary understanding of databases, database managers, and database manager operations as well as of communications. Be careful of nomenclature; there are vast differences between
      a table,
      a database,
      a database manager,
      and a database administrator,
and those differences are critically important. It has been noticed that many use those terms interchangeably, so they might not understand this sub-section. The world of systems and system usage is a complex adults-only environment.

The original purpose of SysLink development was to give to the AxleBase database manager a secure and controlled autonomy on a public network such as the internet. Therefore, SysLink can help with database support for mobile operations, including the fact that high-end database managers usually operate 24-7 as unattended, or autonomous, servers.

Serious high-end database managers offer a universal link to any application through the SQL language. Any app. can be built to communicate with any serious database manager to query a database. Any point-and-click interface that translates the user's commands into SQL commands in the background will allow the user to send sophisticated queries to the database without knowing how it happens. Or power users can enter SQL strings. (The writer has built many and varied applications that used SQL links to various database managers for those who know neither SQL nor databases.)

Mobile operations have peculiar needs for database support, but database managers can have features that serve those needs. For example, AxleBase* has features specifically designed to provide dependable data support in hostile environments. For example, the DBA can configure settings for each AxleBase database to support mobile users with or without SysLink (although the use of SysLink is recommended).

Dangerous Data Returns

      AxleBase is designed to manage databases of many tables with many exabytes in each table, and he could quickly respond to a query joining some of those tables. Those responsible for the networks being traversed and those sharing them might not respond well to that dataset traversing their infrastructure.
      For safety, the database administrator can set a value in each database's configuration that limits the size of data returns. If a query exceeds that value, AxleBase* will return an error to the user who can then correct his query or use the mechanism described below to incrementally retrieve his massive dataset.

Broken Data Connections

      A broken or noisy connection to a standard database manager requires that the query be resubmitted and rerun, thereby straining expensive resources and users' patience. The DBA can tell AxleBase to automatically handle that problem.
      If a connection is broken after initiating a query, AxleBase will continue running the query and save the return when finished. He will then continue processing other queries while waiting for the user or his app to reconnect and ask for the saved dataset. If the break occurs after the return begins, AxleBase will save the unretrieved portion of the dataset until it is again requested.
      The return of the dataset will resume until complete or until the connection again breaks. AxleBase is designed to build and return datasets larger than any computer can handle, so such a return can be interrupted and resumed many times. That feature supports many users simultaneously in continuous operation.
      Perhaps that feature will encourage those who investigate P2P (peer to peer) and other networks that may be cut frequently.

Deferred Data Returns

      The mechanism described for broken data connections can be controlled by the user without DBA configuration. If the user has a query that will run a long time, he can identify it as deferred, submit it, turn off his cell phone to take a nap, and reconnect later to get the results.
      This feature can support installations that serve both mobile and fixed station users. The fixed station user will conserve the resources that would otherwise be used by the mobile users' deferred returns.

Mangled Data Returns

      Datasets can be disrupted in transit by undetectable tiny ambience anomalies that might not affect other types of communications. (I isolated and identified this problem in a network of twenty thousand workstations, and a multitude of autonomic processes, that used various big-name database managers.) Therefore, AxleBase allows the user or the user's app to request retransmission of all or specified parts of large datasets.

Data Security

      Security is built into serious database managers and access to data can be controlled as tightly as desired. Each database has its own security settings administered by the DBA. (Some of these features are found only in AxleBase*.)
      Where an owner is nervous about mobile access to his database, there are features that can impose universal restrictions. Because AxleBase* can manage gigantic tables that are too big to be backed up, each database has a switch whereby the DBA can deny all DDL operations to protect tables. Similar switches can override security to deny all data updates and table scans of large tables. (A table scan is a query that performs at least one read that does not use an index, which could run for years against an AxleBase-class table.)
      If SysLink is not available, the DBA can turn on encryption, which will cause all data returns to be encrypted. The user cannot turn that off, but if the DBA is not using that feature, the user can flag his query to tell AxleBase to encrypt his return. That feature is constructed so that an app can add the flag to each query.
      If the DBA activates the SysLink interface, then AxleBase* accepts and sends only SysLink traffic with floating-key tri-level encryption and authentication.
      If the DBA turns on permission security, access permissions must be assigned to individuals and/or groups using the standard CRUD model with AxleBase* extensions. Permissions are create, read, update, delete, execute, metadata update, etc. Installation domains and databases also have access permissions. Each user must then be assigned permissions for domains, databases, tables, etc., thereby creating vertical and horizontal security partitions.
      Sensitive data should not be casually exposed to mobile access, but where it is needed, the DBA can activate a hardened audit trail for every data row in the entire database. After activation, that feature's hardness prevents de-activation even by the DBA. Each row in the database carries its own detailed audit data that cannot be accessed, and audit history can be destroyed only by destroying the entire database and its backups. Audit trails are in addition to standard logging by the database manager.
      AxleBase was designed for unusual uses, so the security features administered by the DBA are a longer list than covered here. If the installation is secure, hardware is locked down, database security administered well, and data in transit protected by SysLink, then support for mobile users will be as secure as possible.

Privacy And Anonymity

      The relational database construct simplifies protection of privacy and anonymity that can be left to the professional DBA during his design phase. If told to protect certain data, he will design the database with that data is in separate linked table(s).
      Since it is a relational database, that table(s) can be easily rejoined to other tables as usual, but only by those who have access permission to that table as described above.
      The database manager will insure that data inserts go into the correct tables.
      ( Estimate speed from the AxleBase Performance document. For small tables, which are the usual, the big name brands are even faster.)
      Note: Data is seldom, if ever, entirely unstructured. For example, although not designed to do so, the SMTP protocol automatically structures email for insertion into relational databases (,which certain spy agencies love).

Dependability

      When enabled and configured, multi-level hot table segmented failover for self-healing, with automatic anomaly detection, can be entirely managed by AxleBase* throughout multiple catastrophic failures. Resilience of the configuration is limited only by allocated resources, and by the service speed that the DBA is willing to sacrifice. (Increasing resilience increases AxleBase attention, thereby degrading performance.)

Server-Side Mobility

      Some specialized mobile operations that exhibit highly fluid and rapidly changing deployment topologies, also require extreme reaction time and high dependability from dedicated local mobile database servers. The size of AxleBase* may be part of the solution because the world's most powerful database manager occupies less than a megabyte of space; i.e., he can be deployed in tiny hardware. (This addresses group operations where speed and deployment topology fluidity substantially exceed those of city traffic, and includes instant catastrophic loss management for multi-node entities.)
      That type of deployment may include the use of a solid state environment, which AxleBase can use, thereby decreasing energy use, increasing response speed, and hardening servers.

Embedded Interface

      AxleBase has his own interface that is always independent of other apps, including those in which he is embedded. All of the above described features are behind that interface and can be accessed and used only through that interface and only where AxleBase allows it. That means, for example, that AxleBase security is only AxleBase security. Database programmers are familiar with this fact and give their software hooks into the database manager's interface for control and querying as needed. With over a half million words, the AxleBase documentation tells them how to do such things.

( Reminder :       Appendices are outside the protocol. )

This is not intended to denigrate SMTP in any way. The power provided to our civilization by elegant simplicity makes SMTP a beautiful tool that should be looked to for design theory. This is suggested only to give to mail the
            management control,
            universal interface,
            advanced security,
            and technology heterogeneity support
of SysLink.

SysLink can be used in various ways to implement mail, so the following are only suggestions that do not exhaust the possibilities. Far more sophisticated systems than are suggested here can be built around the protocol, so long as they maintain its standard. Or you may find that the standard SysLink message may suffice for basic messaging.

Security Recommendations :
      - Remember that the objective is to send and receive messages, and that does not require eye-candy in a mail client.
      - A click on a URL in a message has destroyed security in many corporations and governments, so your client should not recognize a URL.
      - Your mail client should not have the ability to execute anything in a message.
      - Remember that executable code can be hidden in apparently benign objects such as photos.
      - Consider a filter in your server to stop spreadsheets, etc. Do that early in the design before anybody can become accustomed to transmission of dangerous items. That filter should not depend upon object names, but should inspect the transmission.
      - A major objective of SysLink is security, so insure that your developers maintain protocol compliance in your mail system.
      - Remember that the SysLink security foundation is available to your system. You might give your users the ability to flag each message for single, double, or tri-level encryption by the system, and managers might want a toggle for universal encryption.

Payload :
      The protocol isolates the payload from its envelope. That allows your mail client to insert the message and attachments into the envelope without modification.
      Eventually, managers will take advantage of SysLink's universal coverage, so insure that any payloads will traverse the heterogeneity of SysLink routes. See, for example, the Feasibility Study that used SysLink with the AxleBase* encryptor. That encryptor converts every message into the entire ASCII character set, but the entire ASCII character set cannot reliably traverse networked systems, but AxleBase has solved that problem.

Envelope Recommendations :
      Consider the header carefully before starting. It contains slots that can help manage mail traffic.
      For example :
      Slot 23, activity rubric, should contain the literal "mail" without quotes. If anything follows in that slot, it should be separated by a space.
      Slot 22, routing request, can be used to route anything including mail.

Chicken Or The Egg :
      You might not need to wait for others to have mail servers for your mail. If you design carefully, then any SysLink server can receive and process your mail. Maybe your mail load will suffice to encourage organizations to add mail servers.

Mail Server :
      Please see discussions of various servers elsewhere in this appendix. Be aware of all the security discussions as you build.
      It may be preferable for your mail server to be separate from your SysLink server. In that case, the SysLink server could concentrate on the generalized SysLink processing, and then, recognizing the mail flag in slot 23, could pass mail transmissions to the mail server. The increase in complexity caused by the additional server would actually make management simpler. Additionally, your SysLink server could continue in its role as general router and would not be slowed by mail processing.

SysLink Routing :
      Before beginning your system design, consider the SysLink Routing technology. Your SysLink mail will be able to use the TCP/IP stack, of course, but you may eventually (also) want to use the advanced technologies of SysLink routers and SysLink bridges. When they come on line, they will give your mail the ability to traverse heterogeneous networks using TCP/IP, phone systems, SysLink overlays, wireless, hand delivery, etc. The header allows you to address mail to nearly anything, anywhere. The admiral of the fleet can securely send an encrypted note from his phone across unknown types of networks to his submarines.

Universalization :
      Remember that SysLink is designed for communication, with no qualification of that communication. If you design your mail system well, you can be certain that it will find uses that you did not anticipate. The admiral above is no joke, and many high level database administrators would appreciate a communication path to their running database managers, etc.

Legacy SMTP :
      The builders of mail software and servers have made fortunes by including all the things that you were warned about above. They were toys so people became accustomed to bells-and-whistles and eye-candy, so you were forced to live with it. Perhaps you can sell the conversion to the managers by announcing that you are building a secure mail system for them that will be simple to use alongside their present mail system, and then start slowing the legacy system.
      Each legacy SMTP transmission accumulates a routing history header in-transit. Additionally, Big Business has made that header a trash pile of unsolicited advertisements and pseudo-security measures from Microsoft, Google, Yahoo, etc. Messages arrive with many kilobytes in junk-filled headers. Do not allow them to do that to yours. The SysLink protocol requires that the entire transmission be the SysLink envelope; it allows only its own small and valuable envelope header, so a commercialized SMTP routing history header would be a fatal error for a SysLink transmission.

( AxleBase*)

( Reminder :
      Appendices are outside the protocol. Some thought may be given to including this section within protocol. See the upgrade proposal section of the Administrative Text.)

( Comments and suggestions will be received with appreciation. )

The protocol allows the source to be silent without responding. Although that may be confusing to the requester, it maintains source security where needed.

The information request query CCS asks for an informative response. The complete command is in the form:
          ** information return query **>request<
where request specifies what is needed.
      If the remote system elects to respond, it is done in the information return CCS. The complete response is in the form:
          ** information query return **>information<
where information is the requested information or a response.

As a public service provider, the provider should expect malicious attacks. Therefore, it is recommended that the provider require complete compliance with protocol. Likewise, the requester should expect some providers to be facade's for maliciousness, and require protocol compliance. (See the preceding inbound traffic processing suggestions.)

Note that the envelope header has a slot that identifies the message to which it is responding. It is strongly recommended that the responder always use that slot. Intense traffic may be expected around this protocol, and the positive identification of an inbound message with a pending request will assist automated processing.

The content of the query request is generally not covered by protocol to provide the massive amount of freedom required by the operation. However, a controlled categorical query has been inserted into the CCS that can be used for discovery of a remote system's function. See the canonical categorical request in the query CCS.

Although difficult, it is considered desirable to provide a standard structure for responses to the discovery query to assist automated systems. To that end, the following guidelines are recommended.

Service Names :
      The service will be named succinctly.
      Standard English will be used to maintain SysLink security.
      It will be a literal in lower case.
      It will begin with two asterisks followed by a colon.
      It will end with a colon followed by two asterisks.

Service Qualifiers :
      Service qualifiers may be developed.
      The purpose is to ease and assist processing.
      A qualifier will use service name guidelines.
      A qualifier will not contain colons.
      (That allows service names to be used as qualifiers.)
      It should not contain the word "service".

Usage :
      A service name will be first in the response.
      No characters or spaces will preced it.
      A response may contain multiple services.
      Service qualifier(s) must immediately follow the service.
      Additional data may follow all of a service's qualifiers.
      Additional data are such as contacts, contractual
          requirements, descriptions, web sites, etc.
      Responses will not contain two asterisks with an
          adjacent colon outside of service names.

Recommendations :
      A service name should be followed by characters
          13 and 10 for readability by people.
      Subsequent service names in a single response
          should each be preceded by chrs 13 and 10
          for readability.
      A service section closure will reduce processing errors;
          e.g., **service end**

A Response Example :
** information query return **>**:service forwarding:**
      **network bridge**
      **syslink interface**
      **cryption**
      See service.com/bridge.htm/ for more info.
      **service end**
      **:service data storage:**
      **relational database**
      **syslink interface**
      **surety bonded**
      We outsource nothing. We are responsible.
      Contact sam@service.com for details.
      Route billing inquiries to billing@service.com.
      **service end**
      <
The example response offers two services, each of which has several qualifiers and some free-form comments.

Name Examples :
      A few examples of the many possible service names.
      **:service none:**
      **:service authentication:**
      **:service axlebase:**   (#See note below.)
      **:service cloaking:**
      **:service cryption:**
      **:service data gateway:**
      **:service data scrubbing:**
      **:service data storage:**
      **:service database administration:**
      **:service database design:**
      **:service database host:**
      **:service database server:**
      **:service forwarding:**
      **:service letter of credit:**
      **:service letters of credit:**
      **:service network bridge:**
      **:service network terminal:**
      **:service odbc port:**
      **:service organization cloaking:**
      **:service quality monitor:**
      **:service relational database:**
      **:service router:**
      **:service routing:**
      **:service security:**
      **:service security auditing:**
      **:service sensor net design:**
      **:service sensor net host:**
      **:service service register:** (## See note below.)
      **:service surety bonded:**
      **:service surety bonding:**
      **:service syslink:**
      **:service syslink interface:**
      **:service tcp/ip:**
      **:service translation:**
      **:service vpn link:**
      **:service web site host:**
#   Commercial brand names :
          Brand names will often be needed, especially as
      service qualifiers. When so used, brand names are
      forced into conformance with the uniform name
      guidelines.
##   Register Server :
          Internet registers maintain records of services. Those
      registers are publicly available with or without charge.
          Storage of a register in a relational database will
      allow its management at any size. That will also allow
      the use of powerful and fast ANSII-92 SQL queries
      internally and externally.

Additional Names :
      Names may be used without inclusion in this list. The list must be kept small, but you can send a name to john at this domain for consideration. Put "service name" in the subject.

( Reminder :   Appendices are outside the protocol. )

This section addresses and, hopefully, encourages research and development of technologies in media other than the mainstream electronic digital medium. It is not unthinkable, for example, that fluid dynamics will be rediscovered for systems that will operate reliably in electromagnetically extremely hostile environments. (Logic circuits were demonstrated in Scientific American, circa 1960, and elementary versions are being rediscovered, American Scientist, vol. 105, Jun 2017, p. 143.)

Those alien systems will face the same communication challenges that were encountered by electronic computers such as inter-system interfaces. SysLink can be the interface that brings them into the grand community of inter-system communications.

If your particular technology or medium is not shown, please scan those that are, because they contain generalized concepts that may help you. The general thrust is to achieve the SysLink protocol compliance by any system. Where deviation from the norm by the system construct medium is too extreme to allow total compliance, then it must come close enough to allow its terminal and bridge to bring its communications into compliance. (See the Terminals and Bridges sub-section of the Routing section.)

The simple test for a system is whether or not it can communicate with the SysLink community of systems, which requires protocol compliance.

( Comments and suggestions will be received with appreciation. )

Because the wonderful work of the Master Builder is our guide and inspiration, we assume that molecular systems are biological, but that is not necessarily so. We also assume that "molecular" refers to a communication interface, but that also is not necessarily so. This sub-section addresses any system that communicates at, operates at, or is entirely constructed at the molecular level, whether biological, non-biological, or a mixture thereof.

Systems that operate at the molecular level must implement the ASCII character set in the system for their SysLink interface mechanisms. That implementation in molecular code is expected to be simple, and may have already been done by researchers. Implementation details are irrelevant, but there must be a direct translational correspondence to the electronic digital ASCII implementation. Thereafter, the standard SysLink protocol applies to its implementation in the molecular systems.

The nature of the molecular realm may appear to be problematic because the protocol specifies the American English characters and not the numeric ASCII codes. In actuality, of course, the actual transmission is always the numeric codes. Therefore, where the literal English CCS is specified, the molecular system will render the correct ASCII codes, which will be the correct CCS with its literal English, thereby being in compliance with protocol.

Researchers have demonstrated reliable long message exchange techniques that will allow the creation and transmission of standard SysLink messages by molecular systems in single DNA strands.
      ( "Nature" journal, 7 Feb 2013, issue 7435, Goldman et al, pp. 77-80)
      ( "Discover", June 2017, p. 16, Researchers write 215 petabytes into a gram of DNA.)
      ( Discover, Jan Feb 2018, p. 33, CRISPR-CAS9 was used to store information in the DNA of living cells.)

Other Technologies :
      Where the molecular system must communicate with another kind of system, the molecular system must assume interface responsibility; i.e., it must convert and bridge to and from the other technology within itself or by using an external translator and bridge interface. (See the Terminals and Bridges sub-section of the Routing section for additional discussion.)

( At first glance, this sub-section might appear ridiculous in this very high tech document, but old-fashioned print interfaces are an ideal solution for some arcane needs. For example, intercepting electronic communication is simple, but intercepting a bonded and armed courier is not.)

A print interface communicates via printed documents. The system receives and sends communications on a printable surface such as paper. That interface may be between systems and(or) people. SysLink is designed so that a person can manually process its messages.

Regardless of how it is handled, the use of printed documents in the job stream can be a security weak point. However, if that is recognized, then that interface can become a strong point; e.g., it is difficult to legally intercept a document delivered by armed courier, whereas it is simply and routinely intercepted on the internet.

Designers of a print interface must be aware of additional unusual factors such as the behavior of various electromagnetic spectra as expressed by a printed document. Adherence to the SysLink protocol in processing is expected to handle many such problems, but we must remain alert.

Unprintable Characters :
      Implementation of a print interface implies that all characters are printed. Where the unprintable ASCII characters 13 and 10 are specified, they will be replaced on the printed document by the thirteen-character strings "(**chr(13)**)" and "(**chr(10)**)". The required unprintable character 127 will be represented by the fourteen-character string "(**chr(127)**)".
      To maintain security and the sanity of programmers and system administrators, it is recommended that the printed control character substitutes be immediately converted to the protocol's specified characters as the document is red into the system and before any processing is done. If that immediate conversion fails, then the transmission should be rejected.

Formatting :
      Physical line feeds and carriage returns are not necessary and will be ignored in processing the document because they are replaced by the character strings. However, it is recommended that a line feed and carriage return be inserted with them on the printed document so that a person can easily read the document. Readability by people is part of the SysLink security foundation.
      Other visual formatting in the header and footer is discouraged because reliance on it may ensue. Reliance on things that are not covered by protocol may weaken the protocol and produce security concerns.

Spatial Dimensions :
      The print interface presents a spatial dimension variable for which the protocol does not and will not account. Therefore, the following are recommended where the medium is paper:
      Printed messages will be the standard 8.5 inches wide.
      Each message will be printed on a continuous sheet.
      If that is inconvenient, participating systems must print to
      and read from multiple standard 11-inch length sheets.
      Multiple sheet sequencing must be maintained without
      corrupting the message protocol.
      SysLink does not address message segmentation but it does
      provide message serialization.
      A value such as a long authentication that wraps to multiple
      lines must be recognized as such by the system.

Payload :
      The protocol, by intent, does not address the payload. Therefore, the printed representation of some payloads may be problematic.
      It is tempting to offer more solutions here, but that could defeat the universalization objective of the protocol. Therefore, extensive unprintable characters will require prior negotiation between the respondents.
      ( Requests and suggestions for standardization in this matter will be considered with appreciation.)

Other Technologies :
      Where the print system must communicate with another kind of system, the print system must assume interface responsibility; i.e., it must convert and bridge to and from the other technology within itself or by using an external translator and bridge interface. (See the Terminals and Bridges sub-section of the Routing section for additional discussion.)

This is an elementary matter and is included only as a respectful recognition. EBCDIC systems are expected to easily comply with the protocol standards because of mainframe management quality and because EBCDIC and ASCII are conceptually similar.

When cloud computing was first used, it was called time sharing because the users were sharing time on a remote mainframe. The user had a simple terminal, such as a teletype machine, that sent commands to a distant mainframe computer that processed the information and returned a response. That is the essence of what is today called cloud computing.

Therefore, the term "cloud" is primarily just a marketing buzzword. Cloud computing is one or more remote data processors to which many terminals are connected. Even the old time sharing concepts are resurfacing. Cloud computing is only the simple client-server concept that dates back to the early part of the last century. The managers and IBMs of the world are pushing us back into the oppressive anonymity of the "big iron" mainframe data center

( A historical note :
        A life-changing event was sitting at a kitchen table with an acoustic modem and a portable teletype machine in the sixties in St. Louis and playing on mainframes rumored to be in California. The technology and sociology of that event was a science fiction adventure and a promise for that young man, so it is saddening to see the world giving up its glorious freedom and technology dreams to return to those paleolithic tools. That young man was this writer.)

SysLink is specifically designed to safely carry or serve many other protocols. The SysLink protocol intentionally does not address the contents of its envelope. It is, for example, ideally suited to carry such things as EDI data, XML transmissions, SOAP, RDBMS datasets, autonomic system status reports, etc.

You can even use SysLink as a foundation for new protocols. For example see the email suggestions in the Mail System Suggestions section of this chapter.

Please see the Mail System Suggestions section, which addresses the possibility of explicitly using SysLink for mail.

SysLink may carry mail, but SMTP cannot carry SysLink because the SysLink security requires that the entire transmission be a SysLink envelope with contents.

Appendix
Protocol Implementation Tutorial
Chapter
Advanced Topics
Section
Unusual And Miscellaneous Technologies
Sub-Section
Autonomic Systems



Address : jragan.com/syslink.htm#A7.60.60
-- . --

A computer science autonomic system may not be autonomous in the biological sense, but is in a subset thereof. It is designed with a specified degree of identifiable decision independence. In extreme cases, it operates independently of people to accomplish bounded tasks repeatedly and routinely for an indefinite period. ( Since artificial intelligence is not required by autonomic systems, it may or may not be present.)

SysLink was designed to support extreme autonomy.

An example might be a network of remote environment sensors that are tasked with accruing local histories. In that case, a securely dependable communication link with the systems becomes critical for routine data harvesting, system state reports, and system reconfiguration. SysLink can be the solution foundation for that requirement because one of SysLink's specific design objectives was to support autonomic communication operations.

A more complex example is the world's relational database managers that operate 24-7, managing security, servicing data requests from people and machines, managing vast living data stores, and responding to the DBA's reconfiguration commands. The Feasibility Study is illustrative.

The system architect will think of the solution as a sub-system, whether or not it is actually that, that handles communication for the working system. A study of the protocol and of Programming Suggestions & Techniques will reveal that most of the processing will be unchanging with some lookups, such as the current datetime, for each transmission.

When a sensor in the example is ready to send a transmission, such as a data download, it will construct the envelope, populate the header, and then insert the data payload. It will encrypt as needed, and transmit the message. A step-by-step process is presented for the creation and delivery of a message in the Processing Outbound Traffic section of the Programming Suggestions & Techniques chapter.

All inbound message handling will be simplified and secured by protocol usage. If a message does not meet the protocol and required parameters, it will be rejected. The Processing Inbound Traffic section of the Programming Suggestions chapter presents a step-by-step process for safely receiving and validating a message. If it passes, the message processor will pass the contents to the system interface, which will decide on internal routing and(or) processing.

Notice as you read the inbound and outbound processing sections that the entire process is designed for autonomic execution by unattended machines, and is designed to assist the system coders. To insure SysLink security, maybe you could allow communication with the system only through the SysLink interface even if the system uses multiple interfaces; e.g., routers.

Yes, autonomic communication via SysLink may be that easy. Complexity will be mostly in coding the system and in selecting management design options for it. For example, instead of the sensor system deciding when to download, it could wait for a secure SysLink message to bring a download command from the controller node, thereby level-loading the infrastructure.

(   Some want special networks for machines. Nonsense.
      Starting in the last century, this author designed and coded autonomic systems with complex system-to-system and system-to-people interaction including querying database servers, checking hardware, compiling and distributing complex reports, etc. that ran without maintenance on standard networks.
      One of them had run fifteen years at last check, performing high-speed mission-critical emergency work-crew dispatching for one of the world's largest corporations with no errors and no down time. It worked so well in its first major emergency, dispatching twenty-five thousand men around the clock for days, that a plan to move it from its little PC to a million dollar machine was cancelled.
      Just do it; our fear of failure is a tremendous asset.  )

(   System development:
      If autonomic systems communicating with each other seems like magic, note that today's developers build systems on personal computers that watch for events and then react to those events; i.e., event-driven programming. For those systems, the arrival of a message is merely an event, and that event triggers processing of that object through the SysLink sub-system.  )

(     So you now worry that the bad guys also may read this. Stop worrying. One of your security weaknesses has been your failure to admit that criminals and governments exist and that one of every hundred people, in or out of government, is a psychopath.
      Now step back and look at the entire picture. You will see that this is a secure system, and that part of its security lies in the planned and detailed publication of the process because it forces your designer and programmer to carefully implement the SysLink details that protect you.   )

( AxleBase*)

Appendix
Protocol Implementation Tutorial
Chapter
Advanced Topics
Section
Unusual And Miscellaneous Technologies
Sub-Section
Unmanned Vehicles


Address : jragan.com/syslink.htm#A7.60.65
-- . --

This includes UAVs, UUVs, Driverless Cars, and all other unmanned, semi-manned, autonomic, and quasi-autonomic vehicles.

Before continuing, please read the previous Autonomic Systems sub-section. It is essential here.

SysLink offers two things for any system:
      A universal inter-system interface
      and communication security.
Inter-vehicular exchanges are thus supported and strengthened.

A manufacturer cannot create communication for use between only its own products. A product will encounter products of other cultures, political entities, manufacturers, and requirements, and recent history demonstrates that a computer operating system manufacturer cannot assure communication even between its own operating systems. SysLink provides a universal interface that all systems can use and can use in any context with security.

Although not always a critical design factor, prudence dictates that potential processing speed requirements must be considered at project inception. The SysLink message processing overhead is expected to be minimal for the mass of Man's vehicular traffic, thereby yielding an adequate processing speed for that area.

Where extremely high processing speed is dictated, with every byte dear, such as by a need for tight inter-group cooperation during unexpected high speed encounters with malicious or uncooperative vehicles, the SysLink protocol can be used to establish temporary local protocols such as brevity authorization, group topology, inter-group identities, frequencies, encryption, etc. With that foundation, the group can temporarily switch to a succinct exchange protocol for faster reaction-able processing.

At publication of this sub-section in 2016, radio transceivers such as cell phones, tablets, smart phones, etc. were already ideal for the SysLink technology. It needs only implementation in software or hardware on those platforms to secure communications against Big Business and Big Government, and also to give the owners an interface to the world of machines.

There is so much computing power on each of those devices that each can even function as its own SysLink communication server, providing in-transit security with encryption and authentication. It might be entirely automated, or given a simplified SysLink admin. interface for technologically-comfortable users of those devices in an "app". ( Having never used one of those radios, I am not a member of that subculture, so my "app" usage may be incorrect.)

SysLink supports legacy routing via TCP/IP and other carrier protocols. Simultaneously, it provides a new type of routing for SysLink routers that accepts telephone numbers with other protocols in routes. SysLink was designed to traverse unforeseen environments, so a SysLink message can be routed across linked heterogeneous infrastructures of any kind that support SysLink transmissions; e.g., phone circuits with TCP/IP networks. (See the Routing section of this chapter, and the following Network Media sub-section.)

For those who have been developing a new kind of TCP/IP for mobile communications, that may be of some benefit, but we have had mobile communications for years that used only telephone numbers. The AxleBase* database manager accepts industry-standard ANSI-92 SQL in plain text and has special sub-systems to serve mobile workers. That and SysLink means that hand-held radios, such as cell phones, can securely query massive databases now. (See Mobility Support in this chapter.)

Recommendations :
      Promote your system to consumers as "SysLink Capable".
      Provide a SLeD (SysLink-deficient) toggle for communication with systems that do not have a SysLink interface.
      America's NSA ruler lied to congress by claiming that the message header is inconsequential metadata, so the American government compiled detailed communication information of billions of people. Secured SysLink with SysLink routing is recommended for security against all governments.

( AxleBase*)

( If you leave your office door unlocked at night, have a broadband connection on your communication device, surf the web, or download indiscriminately, no security will help you. )

( The CIA wants you to feel helpless, but we can beat the CIA.
      Buy from a reputable radio (phone) manufacturer.
      Secure the phone, including SysLink, before using it.
      Avoid broadband when possible.
      Do not surf the web.)

Although they may be a more natural part of the universe, analog systems are a species alien to digital systems. The machine population has become overwhelmingly digital, and the very concept of communicating with ASCII characters is a digital concept. Conversely, the analog system potentially presents itself in a complex sphere of infinitely varying values as opposed to the discrete bytes of the digital realm. The simple recognition of those facts presents the magnitude of the analog interface problem.

Additionally, even our networks have been digitized. Unfortunately for bigger issues, even the telephone system has been surreptitiously digitized right up to our doorsteps. Therefore, an analog system cannot universally communicate in its natural analogue mode.

Furthermore, any communication in today's world is subject to insecurities. Giving SysLink to analog systems would give more than an interface; it would bring them into a more secure circle.

We cannot presume to speak to the engineering of analog systems, but perhaps the above problem statement indicates a strategy for a solution that lies in the architecture of those systems. An internal sub-system in the analog system is proposed that would be an analog-digital translator. That translator would be an interface to an internal digital SysLink sub-system that would interface to the digital world.

In that solution, the system would feed its analogue data into its internal translator. From there the translated data would go into the digital SysLink sub-system. That sub-system would generate and output SysLink transmissions, and receive in reverse.

The location of that solution is important due to data morphology. Sinking ever deeper into digital technology, we tend to forget that we are withdrawing from reality. Analogue data is not perfectly translatable into discrete characters because the analogue is closer to reality with more data than the digital world can absorb; e.g., our old chemical film photos that could be expanded to billboard size, compared to pitiful digital images. Therefore, characteristics of the data might be known only to the analog computer engineer, and he would be best qualified to preserve the required data accuracy.

SysLink was designed to carry anything that can be digitized.

SysLink is designed to be a universal interface that supports extreme security in transit. Those two features, interface and security, will not be compromised despite pressures to do so. Therefore, the processing overhead may be detectable by the interlocutors, so perhaps SysLink should be used for transporting conversations only under one of these conditions:
      The system can process faster than the conversation.
      Or participants are at ease with brief pauses.
The latter may be encouraged by knowing that pauses are caused by deep security processing.

( For overhead, see the Processor Load sub-section of the Processing Inbound Traffic section, and for speed, see the Feasibility Study section. )

The problem can be ameliorated somewhat by engineering design. For example, when a conversation begins, the SysLink envelope can be staged. The conversation will be digitized in progress, so that digitization can be written into the envelope as it is generated. Encryption can be triggered when the send cue is triggered, or the conversation might be electronically garbled as it is generated.

As each envelope is sent, another will be generated and staged. Conversation pauses can be used to stage multiple envelopes in a queue, encrypt and send the current envelope, or receive and process an inbound envelope.

Professional interlocutors, who are accustomed to such things, might use the old standard military net RTO protocol, which can be detected in conversation by a processor. Processing and communication activities could then be cued by the conversants' use of the RTO protocol.

Recommendations :
      See the "Cell Phone" sub-section for additional discussion.
      America's NSA ruler lied to congress by claiming that the message header is inconsequential metadata, so the American government compiled the detailed communication information of billions of people. Secure SysLink with SysLink routing is recommended for security against all governments.

With the security features of SysLink, even cell phones might fill the old fantasy of extremely secure conversations for the common man.

Implementation in hardware will be unneeded in most applications because SysLink will create very little processing overhead and will be easy to implement in software. However, it might be used to :
      Reduce programming proficiency requirements.
      Increase reliability.
      Increase security.
      Insure protocol compliance.
      Serve the mass market.
      Service extraordinary speed requirements.

The design and presentation of the protocol is expected to ease chip design. In turn, that should ease programming to the chip's API.

Message contents are insulated within the envelope and will be of little or no concern to the chip except for insertion into the envelope. However, by design, there is no limit on the size of the contents. Therefore, the chip
      must discern and react to the message size,
      or the size of the application's messages are identical,
      or the application can limit and(or) segment messages.
In any case, the chip design should address that concern.

Encryption is another reason for return of an outbound message. If the chip cannot handle tri-level encryption, then the message must be returned to the system for encryption.

When used for outbound messages, some data, such as lengths and datetime could be entirely calculated and entered by the chip. Additional data might be on-chip in market-segment-dedicated builds. The hardware must be carefully designed to comply with protocol. All data must be in person-readable English.

Interestingly, the construction of the protocol can make processing of inbound traffic by hardware easier than outbound traffic for some applications. Hardware can certainly screen out most traffic that does not comply with protocol specifications, or hand it to the software with reservation flags.

Hardware obsolescence projections will be a management factor. The protocol is designed to mitigate that problem with its release management. It requires that every message carry in the envelope header the release number of the protocol used in it. Protocol changes are always announced in the Release Identification, and proposed changes are usually announced except for emergencies. Thus far, protocol releases have been able to maintain backwards compatibility, and that will be attempted in the future to support backwards compatibility for legacy systems.

Step-by-step instructions for the creation of outbound messages and the processing of inbound messages are presented in the Processing Outbound Traffic and the Processing Inbound Traffic sections of the Programming Suggestions & Techniques chapter.

Caution :
      Any deviation from protocol of even the slightest degree will endanger the security of the entities using the hardware because it will be detectable and SysLink systems will be attacked.

( Regardless of hardware implementation, the intent is to support the common man's software coding in all future protocol releases.)

( Comments will be received with appreciation. )

Other than requiring digital payloads, SysLink is data-neutral. Although there has been no great effort made to search for exotic data and data structures to test, no problems are expected because of the SysLink structure, the digital requirement, and performance during the Feasibility Study.

The SysLink protocol explicitly segregates the envelope from its contents without exception. No overt provision is made or sought for containerization of data that is not digitized. (But comments will be received with appreciation.)

The Feasibility Study used SysLink with the AxleBase* encryptor, which converts messages into the entire ASCII character set. The entire ASCII set will not reliably traverse systems, so AxleBase universalizes encrypted transmissions as a final step. The study transmitted queries, commands, responses, and formatted data returns that ranged from a few characters to megabytes. Various data structures can be selected for AxleBase returns, and all were used. All traffic used tri-level floating-key encryption without fault or error for several years.

Streaming media is becoming popular for large datasets. Storage, management, and return of it is simple for managers such as AxleBase*, but delivery can be troublesome. If SysLink power is wanted, SysLink can deliver objects of any size. SysLink supports segmented delivery of large datasets for automatic redelivery of lost or damaged segments. The use of SysLink prepares the source system for universal interaction with a heterogeneous customer base, and offers a strong framework for security against in-transit piracy.

( AxleBase*)

Working in new territory, SysLink was conceived for electronic networks running digital TCP/IP over cable. While the concept was still being developed, SysLink was then generalized to any medium and any transport protocols. Thus, if the network can
      carry ASCII character codes,
      route traffic,
      maintain message integrity,
      and deliver discrete transmissions,
then it will probably support SysLink communications.

Fiber optic, free photonic, acoustic, radio, other electromagnetic spectra, print, water, vacuum, hand-delivered storage, Morse code, biological channels, military net protocols, and others were considered during the design. Some because they would surely be used, and some because they set the generalized network concept space such as the Napoleonic-era semaphore system.

Furthermore, SysLink is designed so that SysLink servers can link nearly any kinds of network media and network protocols that carry SysLink. For additional discussion of heterogeneous network integration and management, see the Terminals, Bridges, And Routers sub-section of the Routing section in this appendix.

( NOTICE:   Content distribution (CDN), content centric (CCN), and information centric (ICN) network types are being designed to violate copyrights to steal intellectual property, so they will not be evaluated or considered because they are organized crime on a global scale that reflects moral decay caused by globalization of our affairs.  )

Possible Confusion:   The protocol specifies use of the characters in a SysLink transmission; not their codes. ASCII codes are referenced in the protocol to assist those for whom English is not a native language or who are not American, and for specificity to positively identify the characters used.

This table does not include all ASCII (American Standard Code for Information Interchange) codes.

These are the numeric codes for the characters that are printed in CCS, in the envelope header, and in the footer. Chr(103), for example, corresponds to the letter "g" that is used in the protocol, but chr(71) is used only in identifiers because it is the upper case "G".

Additionally, the protocol specifies the use of the unprintable characters 13, 10, and 127 as controls.

SysLink was built for the AxleBase lab to provide a generalized communication interface between various systems. After AxleBase received the ability to configure into a super-system, that interface became increasingly important and more sophisticated.

SysLink was next made publicly available to encourage potential buyers to try AxleBase. The intent was to help them build systems that interfaced to the various AxleBase demonstrators. (That offer was later withdrawn.)

It was realized after completion of the AxleBase project that the world's businesses and governments could use SysLink. My past contractual projects with EDI, chain store operations, XML, and data movement in big business could have benefited from SysLink interfaces, and surely that was true of many other professionals.

It would be used only if it were freely available so that institutions could ask each other to implement it. Therefore, the SysLink protocol was released to the public and began improvement.

Please forgive this, but it is important to millions of people:
      Unlike the open source hordes that put men out of work by giving free software to big corporations, it is hoped that SysLink will have the opposite effect. Although simple for a professional, the building of full-featured SysLink processors could use many manhours on a world scale if the open source hordes let it alone. Also, increased control, security, and ease of communication between business entities should help professional employment.

SysLink does not deny additional layers in the network stack. For example, SysLink can carry SMTP (mail), ODBC (open database connectivity), HTML, XML, SOAP, SQL, jpg, text, etc.

Any language or protocol that does not conflict with the SysLink protocol can be carried by SysLink. A transmission construct of
            SQL/ SOAP/ SMTP/ SysLink/ TCP/ IP
would be permissible and highly controllable.

The Language Recognition sub-section of the Universalization section provides additional support.

The following shows history of protocol changes published in the Current Release section. See that section for "release" definition.

Release:   180101
The envelope's slot 9 date specification is altered
to allow other protocols, but with great deference to
the CoreDate protocol.
Proposal(s): none
________________________________________

Release:   161207
The envelope's slot 18 specification may have been
ambiguous. The word "enclosure" was changed to
"envelope content; i.e., encryption level 2"
to improve clarity.
Proposal(s):   25
________________________________________

Release:   161202
      In envelope slot 23, which is the rubric,
      the description words
            "is an organization's designator"
      were changed to
            "may be an organization's designator"
      For envelope slot 6, which is the footer length,
      the following description words were appended:
            "and the footer delimiter"
Proposal(s):   none
________________________________________

Release:   none   Date:   160529
Reversal     Proposal 22 was not implemented.
      - It proposed an explicit interface to and between
        systems that do not use digital computer processing.
It was withdrawn after a ten month consideration.
See instead the Unusual Technologies section of the
Protocol Implementation "Tutorial" appendix for
handling of those system interfaces.
________________________________________

Release:   160104
      - Security hardening of the information request CCS.
      - Discovery formalization and standardization by
    addition to the information request CCS of an optional
    categorical discovery request.
Proposal(s):   20
________________________________________

Release:   150531
      - Denied unicode in the envelope for security.
( It was already implicitly denied elsewhere. )
Proposal(s):   19
________________________________________

Release:   141227
      - Inserted a digit into the release number to span decades.
            ( To allow generation and support of legacy systems.)
      - Increased the identifier length to 60 characters.
            ( To assist the NSA, FBI, China, France, etc.
            in spying on and controlling Americans.)
      - Increased identifier universalization.
      - New CCS can explicitly accept a session request.
            ** session request accepted **><
Proposal(s):   16, 21, 17
________________________________________

Release:   140826
      Altered the CCS that specifies envelope size limit to
          allow each participant to set its inbound limit.
      Expanded and clarified its descriptive text.
Proposal(s):   15
________________________________________

Release:   140404
      Added optional routing request in envelope slot 22.
Proposal(s):   14
________________________________________

Release:   140303
      Specified envelope punctuation and special characters.
Proposal(s):   none
________________________________________

Release:   140125
      Added two optional envelope header slots.
            A user name for legacy security.
            A matching password.
      New CCS ** end this syslink session **
            replaces **break our comm connections** because
            perceived semantics were too unlike the operation.
Proposal(s):   11, 12, 13
________________________________________

Release:   131210
      - Increased fault tolerance for session closure.
      - Allowed specification of a session ID in session request.
      - Expanded session identifier CCS to support the change.
Proposal (s):   none
________________________________________

Release:   131130
      - Clarified and generalized system coverage of the
        **reverse connection to port** CCS.
Proposal(s):   none
________________________________________

Release:   130322
      - Inserted four header slots before the authentication.
      - Created the Activity Rubric header slot.
( Since authentications can be problematic for programmers, the new slots were inserted before the authentication slot to keep it in the final position. )
Proposal(s):   9, 10
________________________________________

Release:   120910
      - Clarified and restated encryption and compression.
Proposal(s):   none
________________________________________

Release:   120704
      - Expanded specification options for the resend CCS.
      - Expanded identifier specification to support the above.
Proposal(s):   none
________________________________________

Release:   120604
      - Tightened the specification of identifiers.
      - Implemented optional message serialization for tighter
        security, increased control, and synchronous sessions.
      - Implemented payload language identification.
      - Added an optional transmission acknowledgment CCS.
      - Added the stack ordinality specification.
Proposal(s):   5, 6, 7, 8
________________________________________

Release:   120512
      - Added the CCS stacker to the protocol.
      - Reworded session openers for clarification.
Proposal(s):   4
________________________________________

Release:   120412
      - Specified Arabic digits in header.
      - Added a local error report CCS.
      - Excluded ASCII characters 13 and 10 from header,
        except as terminators, to simplify processing.
Proposal(s):   1, 2, 3
________________________________________

Release:   120323
      - Some definition clarifications with no protocol change.
Proposal(s):   none
________________________________________

Release:   120116
      - Added an error type to the error handler CCS.
      - Clarified the server envelope.
      - Expanded the authentication request.
        ( Without changing the existing request. )
Proposal(s):   none
________________________________________

Release:   111118
      - Enhanced and clarified various definitions.
Proposal(s):   none
________________________________________

Release:   111101
      - A major upgrade. Restructured and expanded the envelope header. Added new commands. Added error handling.
Proposal(s):   none
________________________________________

Release:   091101
      Initial publication on or near 1 November 2009.
________________________________________

Apologia if AxleBase references appear to be commercial advertisement, but AxleBase is NOT available. It might never be available because its public use requires purchase by a technology company for marketing, support, and continued development.

SysLink was created initially to serve AxleBase communication and security requirements including deployment in the hostile environment of the internet. Most of the protocol's basic features were developed to serve an AxleBase need. Naturally, that past intimate association frequently causes any thoughts about SysLink to raise thoughts of the SysLink-AxleBase interaction. (See the Technology History.)

Also, AxleBase provides useful examples because
      it is an advanced technology
      that provided a platform for research and development,
      and because it was given unusual communication features
      and sub-systems to support its advanced objectives.

AxleBase development began sometime around the turn of the century. Its internet domain name was purchased in 2003. Except for some tinkering and personal usage in the lab, development has stopped.

More advanced, but less finished, it is similar to the Oracle and MS Sql Server relational database managers. It is the world's only relational database manager that can handle hundreds of billions of rows per table with ease, economy, and unmatched speed. A description of its advanced features, oriented toward data professionals and computer science academics, can be found on this web site.
(It is totally unlike the new NoSql systems that are far cheaper, simpler, and not relational.)

Correspondence should be sent to john on this domain with SysLink as the subject.

Comments, suggestions, and questions are welcome. SysLink implementation reports are appreciated.

1. Remember that a SysLink communication session is independent of the hardware and lower protocols, and is controlled by the participants.
      A server might employ an intermittent power-down operation without session closures if the server does not want to close sessions during brief controlled power-downs. In other words, although it is discouraged and might confuse interlocutors, a system can power down without ending sessions. (Suggested by Doctor Antonopoulos of CTTC in a COMSOC announcement, 15 June 2017.)
      To avoid disruption and confusion, it is strongly recommended that the administrators of participating systems be made aware of the use of this practice before session creation.

This work area is merely a notepad. Anything in it will certainly change or disappear. Nothing about it is firm. Even absence from it means nothing.

Comment about it or about anything in or not in it will be reviewed.

If complaints are received, it may be removed entirely, but years of one-man project work has shown no effective way to manage incipient ideas other than by embarrassing myself in this manner.

_________________________

optionality in coherent communication

can universal coherency of communication threads / sessions be maintained with embedded optionality ?

see comments in the 'optional ccs' sub-section.

should a generalized response to optional ccs be required ? nope! that would compromise security.

is the denial of transmission ccs sufficient or is another needed ? theoretically, conceptually, practically....

system universalization

Web site and technology
Copyright 1999 - 2023 John Ragan

Web site is maintained with Notepad.
By intent, and I don't discuss it.