Network Working Group                                         J. Sharp
Internet-Draft                                          FRST Computer
Intended Status: Experimental                                May 2026
Expires: November 2026


           Positioned Gopher: A Coordinate Extension to RFC 1436
                          draft-sharp-gopher-pos-01


Abstract

   This memo defines a minimal, backward-compatible extension to the
   Internet Gopher Protocol (RFC 1436) that permits menu lines to
   carry optional pixel coordinates.  The extension enables spatial
   layout -- text regions, buttons, input fields, and bitmap images
   -- over the existing port-70 request/response model without new
   item types, sessions, or scripting.  Clients that do not
   implement this extension render positioned menus as ordinary
   linear menus.

1.  Conventions

   The key words MUST, SHOULD, and MAY in this document are to be
   interpreted as described in RFC 2119.

2.  Protocol Extension

   RFC 1436 defines a gopher menu line as:

      <type><display>\t<selector>\t<host>\t<port>\r\n

   This document permits one additional, optional, tab-separated
   field following <port>:

      <type><display>\t<selector>\t<host>\t<port>\t<position>\r\n

   where <position> is:

      position = x "," y [ "," w "," h ]
      x, y, w, h = 1*DIGIT      ; non-negative integer pixels

   A line bearing <position> is POSITIONED; one without is LINEAR.
   A menu MAY mix the two.

3.  Client Semantics

   A client supporting this extension SHOULD render positioned lines
   at their stated coordinates relative to the top-left of its
   content canvas.  Linear lines in the same menu MAY be rendered
   after positioned content in conventional list form.

   A client not supporting this extension MUST ignore the trailing
   field per existing gopher extensibility and render the menu
   linearly.  Backward compatibility is total.

   Coordinates are absolute pixels.  The canvas size is
   implementation-defined; servers SHOULD author against the
   largest viewport they intend to support.

4.  Element Rendering

   Existing item types acquire spatial semantics when positioned:

      i  static text region; not interactive
      0  text button; activation fetches the selector
      1  menu button; activation navigates to the menu
      7  single-line input field; submission uses the standard
         gopher query mechanism of RFC 1436
      I  bitmap image (format implementation-defined)
      p  1-bit PBM image (P4 format; FRST extension)
      9  binary download trigger

   When w and h are present they bound the element; when absent the
   element is sized to its natural extent.  Z-order is line order:
   earlier lines render below later lines.

   Empty-label hit regions (non-normative): when a positioned type-0
   or type-1 item carries an empty display string, clients SHOULD
   render it as an invisible hit region -- the bounding box remains
   responsive to activation but no visible chrome is drawn.  This
   permits imagemap-style overlays in which clickable regions are
   placed over a backdrop bitmap without obscuring it.

5.  State

   This extension introduces no session, cookie, or scripting
   mechanism.  Application state MUST be encoded by the server into
   the selectors it emits.

6.  Security Considerations

   This extension inherits the security properties of RFC 1436,
   namely none.  Implementations SHOULD treat received bitmap
   payloads as untrusted and bound rendering to the declared canvas.

7.  Example

   A card with a header, cover image, search field, and two
   navigation buttons (tabs shown as spaces for readability):

      iWelcome to the Library  fake          err  1   20,20
      pCover                   /img/cover.pbm srv 70  50,60
      7Search                  /search        srv 70  20,300,360,24
      1Fiction                 /fiction       srv 70  20,360,180,40
      1Non-fiction             /nonfic        srv 70  210,360,180,40
      .

8.  References

   [RFC1436]  Anklesaria, F., et al., "The Internet Gopher
              Protocol", RFC 1436, March 1993.
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

Author's Address

   Jon Sharp
   FRST Computer
   Email: jrsharp@frstcomputer.com
