1 files changed, 218 insertions, 0 deletions
diff --git a/doc/rfc/rfc125.txt b/doc/rfc/rfc125.txt
new file mode 100644
index 0000000..de3b6c4
--- /dev/null
+++ b/doc/rfc/rfc125.txt
@@ -0,0 +1,218 @@
+
+
+
+
+
+
+                         NETWORK WORKING GROUP
+
+                        REQUEST FOR COMMENT: 125
+
+                                NIC 5841
+
+
+
+
+                             APRIL 18, 1971
+
+
+
+
+
+
+
+
+
+
+
+
+                             JOHN McCONNELL
+
+                          AMES RESEARCH CENTER
+                       MOFFETT FIELD, CALIFORNIA
+
+
+
+
+
+Response to RFC #86, Proposal for Network Standard Format for a graphics
+data stream.
+
+
+
+Category         D.6
+RFCs obsoleted   None
+RFCs updated     86
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+The basic approach of transmitting an intermediate, device independent
+language which is translated into specific device codes at the
+receiving host is sound. It appears to be the only approach that will
+allow thought to be centered on picture descriptions. Ames Research
+Center has adopted this approach in tying its graphic facilities, of
+various types, and on various computers together. At present, we are
+in the design phase and expect our package to be running in about six
+months. The main objections to the structure as it now exists, is that
+it takes no cognizance of the many features available on graphics
+devices. Since these features will always be changing with new
+devices, a set of option or mode primitives should be defined which
+are logically separate from the drawing primitives provided in RFC 86.
+The mode primitives will act upon the drawing primitives to modify
+their actions. The scope of a mode primitive extends until a new mode
+primitive resets an option. The use of mode primitives will allow the
+network standard stream interpreter to treat them as null operations
+if the features are missing at a particular host, or to perform more
+detailed interpretation of the following data stream to achieve
+results. The drawing primitives may also then keep a standard format
+which need not be changed to incorporate new features.
+
+Overall modes which primitives could control would be intensity
+levels, or color selections for objects, in addition blinking of
+objects should be provided. For vectors, the additional facility for
+drawing dashed lines is necessary.
+
+Character strings require another set of specification. The convention
+for the beam is usually that it is in the center of the rectangular
+area defining a character's boundaries. The beam position is usually
+undefined at the finish of drawing a character string. A strong
+exception is taken to the exclusion of form control characters from
+strings. If included in the character string, they could provide for
+shifting from upper to lower case, subscripting, superscripting, and
+underscoring, as well as tab and other "carriage" motion functions.
+The appropriate characters could be extracted at interpretation time
+to provide the necessary information to display more complex strings.
+To allow the facility for generating ALGOL-like delimiters, such as
+"then", a convention for canonical character string should be adopted.
+I believe the Multics conventions described in reference 1 will
+suffice.
+
+Additional options for character strings should include a size
+specification and an orientation selection. As many devices, have
+hardware character generators that are fixed, some of these options
+may not be desirable to implement as subroutines.
+
+Another area that should be looked at further is the additional
+symbols available which are not specified in ASCII. Some means of
+
+
+
+                                                                [Page 2]
+
+defining them should be provided within the argument string itself,
+again Multics has allowed the specification of arbitrary characters by
+entering their octal equivalents. The convention should use a control
+character code followed by a l6-bit list name which specifies the
+sub-list defining the character. The other alternative is to allow
+8-bit characters and allow the interpreter to choose a sub-list if the
+character is not realizable with a hardware generator.
+
+The special form control characters to be used are:
+
+    a. BS    - backspace
+    b. LF    - for new line
+    c. SO/Sl - shift case
+    d. DC2   - superscript following characters
+    e. DC4   - subscript following characters
+    f. DC3   - special non-ASCII character follows
+    g. Tab   - position to next tab. May be predefined or specified.
+
+Another construct should be added to those proposed in RFC 86. This is
+the display list pointer (NGDLP). It will have as a value the next
+drawing primitive to be executed. The value is a displacement from the
+head of a list. With no mode setting primitives, this value is one to
+one with the drawing primitives transmitted in the NGDS. The NGDLP is
+needed for consistency for execution of the nested list structure.
+Whenever an execute list primitive is encountered, the current value
+of the NGDLP is saved along with the list name and current origin
+value. When execution of a list is finished, the last values saved are
+restored.
+
+An include list primitive would allow the treatment of a sub-list to
+be equivalent to a macro instead of a subroutine. This would be
+necessary to avoid changes to all sub-pictures on the screen due to
+the manipulation of a sub-list. The include primitive should have as
+parameters such specifications as size, intensity, orientation,
+blinking, etc. After a sub-list has been included in another list, it
+is no longer distinguished as a separate entity.
+
+To cut down on the volume of data being transferred, other commands to
+be parsed by the stream interpreter should be added. These would allow
+the manipulation of a list by the receiving host without a
+retransmission.  The types of manipulations would include rescaling
+the coordinates for shrinking or zooming, translation of the origin,
+or rotation. Other manipulations to provide for displaying or not
+displaying a list, or enabling of disabling light pen detections would
+be desirable.
+
+The problem of interaction with the displayed picture has yet to be
+addressed, so this will be an attempt to elicit some more discussion
+
+
+
+                                                                [Page 3]
+
+in this area. The use of a keyboard or function keys poses no problem
+in that both can be handled as a standard message from the graphics
+terminal. The use of devices that interact with the picture or the
+screen such as light pens, mice, joysticks, or tablets presents a
+different and more complex problem. This problem is the standard one
+of making an association between the point selected and some
+meaningful entity such as a list or a primitive. This association
+should be made at the receiving host since the NGDS has been changed
+in unknown ways.
+
+To allow the transmitting host to identify the object pointed at, the
+stack of suspended lists and the current value of the NGDLP will
+qualify the object to any level in a hierarchical structure. In
+addition, normalized x,y coordinates should be returned, as well as a
+character displacement if a string was pointed at. This structure will
+serve a light pen device very well since the light pen mechanism
+allows the determination of the currently executing primitive. Other
+devices interact with the picture in an asynchronous fashion and the
+association of an x,y pair to a structure is a more difficult problem.
+This may require that the host generating the graphic data stream be
+responsible for making that association. A further complication arises
+when it is desired to use a light pen in an area where no beam motion
+occurs, then some directive to periodically sweep the screen and
+"find" the pen must be provided. This might be a sub-list which is
+executed periodically for this function.
+
+
+       [ This RFC was put into machine readable form for entry ]
+        [ into the online RFC archives by Jerry Tenenbaum 4/97 ]
+
+---------------------------------------------------------------------------
+Reference: Osanna, J., Sahzer, J.
+           Remote Terminal Character Stream Processing of Multics
+           Proceedings SJCC, 1970, p. 671
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 4]
+