[comp.protocols.misc] info needed on "NAPLPS"

shuford@cs.utk.edu (Richard Shuford) (02/19/91)

The BYTE article series about the North American Presentation-Level-Protocol
Syntax (NAPLPS--which may be pronounced like "nap-lips"):
   
  NAPLPS: A New Standard for Text and Graphics, Part 1: Introduction.  Jim
  Fleming and William Frezza.  BYTE, February 1983, Vol. 8, num. 2., p. 203.

  NAPLPS: A New Standard for Text and Graphics, Part 2: Basic Features.  Jim
  Fleming and William Frezza.  BYTE, March 1983, Vol. 8, num. 3., p. 152.

  NAPLPS: A New Standard for Text and Graphics, Part 3: Advanced Features.
  Jim Fleming and William Frezza.  BYTE, April 1983, Vol. 8, num. 4, p. 190.

  NAPLPS: A New Standard for Text and Graphics, Part 4: More Advanced 
  Features and Conclusion.  Jim Fleming and William Frezza.  BYTE, May 1983,
  Vol. 8, num 5., p. 272.

(I was working for BYTE at the time, and I served as the theme editor for
that February 1983 issue on standards.)

It may be fair to say that the North American Presentation-Level-Protocol
Syntax (not "standard") grew out of the efforts in the early 1980s to
create a mass market for what was variously called "teletex" or "video-
text" (although at the time nobody could agree on what these terms really
meant).  The basic idea was for delivery of information to a nontechnical
user base who were nonetheless familiar with video games and wanted to see
pretty graphics.

As I recall with some memory haze, there were two general graphics schemes
developed for teletex.  One was used in the British Prestel system, and I
think it was called "alpha-mosaic".  The other, somewhat more sophist-
icated technology was pioneered in Canada with Telidon, an "alpha-
geometric" protocol.  A key feature is the extension of the ASCII-type
codes to include Picture-Description Instructions (PDIs).  Some of the
advanced features of Telidon were incremental lines, macros, dynamically
redefinable characters, chain-encoding of shape edges, and various types
of display fields.

AT&T added some features to Telidon and handed NAPLPS to the ANSI-
accredited standards committees and said, "Here.  Bless our standard," so
the X3L2 (technical) Committee on Character Sets and Coding worked on it
for some time.  The draft document was BSR X3.110-198x; I don't know the
numbers of any successor documents.  Fleming and Frezza, who worked with
the protocol for AT&T, were on this committee.  

In my opinion, a major handicap for NAPLPS was that for a long time the
only equipment available for encoding the images was a special computer
sold in the United States only by AT&T, costing tens of thousands of
dollars.  This major capital start-up expense delayed or killed a lot of
creative ideas for using the NAPLPS protocol and/or teletex.  Eventually
there were some cheaper encoding products, based on an Apple or IBM
PC-type platform, but the initial enthusiasm had already declined.

The significance of the "presentation-level" part of the protocol's name
has also been changed by events.  The real OSI protocol stack, which was
amorphous indeed back in 1983, now has a pretty firmly defined Presentation
Service.  So the Abstract Syntax Notation 1 (ASN.1) and its Basic Encoding
Rules (BER) now occupy that slot.  I suppose that somebody could adapt
NAPLPS as an alternate to ASN.1/BER for certain applications, but the
effort to make it mesh with the other OSI layers would be nontrivial.

The CoSy conferencing software used by BIX (the BYTE Information eXchange)
contains support for transmitting NAPLPS images to its users, but this
feature has been rather neglected in recent years.  There used to be some
NAPLPS-encoded images in one of the BIX graphics conferences, but I don't
know if these are still online.

I was not aware that Prodigy is using NAPLPS.  The concept certainly makes
sense.  It could be the beginning of a revival of interest in this unique
-- 
....Richard S. Shuford  | "Do not rebuke a mocker or he will hate you; rebuke
....shuford@cs.utk.edu  |  a wise man and he will love you.  Instruct a wise
....BIX: richard        |  man and he will be wiser still."  Proverbs 9:7 NIV

rpw3@rigden.wpd.sgi.com (Rob Warnock) (03/11/91)

In article <1991Feb19.043620.12415@cs.utk.edu> shuford@cs.utk.edu
(Richard Shuford) writes:
+---------------
| In my opinion, a major handicap for NAPLPS was that for a long time the
| only equipment available for encoding the images was a special computer
| sold in the United States only by AT&T, costing tens of thousands of
| dollars.  This major capital start-up expense delayed or killed a lot of
| creative ideas for using the NAPLPS protocol and/or teletex.  Eventually
| there were some cheaper encoding products, based on an Apple or IBM
| PC-type platform, but the initial enthusiasm had already declined.
+---------------

Historical trivia: During the development of the Fortune Systems 32:16
desktop Unix computer (circa 1981), we had a big internal argument about
whether the Fortune-supplied ASCII terminals were going to used ANSI X3.64
or NAPLPS for their character sets and control codes. X3.64 was (and is)
largely identified in many people's minds as being "vt100", mainly because
DEC was one of the first volume terminal manufacturers to embrace X3.64,
although by 1981 dozens of manufacturers had publicly announced support
for X3.64.

But the marketing guys said, "AT&T is bigger than DEC", and NAPLPS won.

Of course, look around today and compare the number of async 80x24 terminals
that do X3.64 ("vt100 compatible") versus the number that do NAPLPS...  ;-}


-Rob

p.s.
The Fortune terminal used only the ASCII and character-block-graphics
subset of NAPLPS, so it wasn't "really" a NAPLPS terminal, in the sense
of any kind of videotext capability.

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311