Subject: IPP> What ever happened to IEEE 1284.1 (aka TIPSI, aka NPAP)?

From: Jay Martin <[email-masked]>
Date: Fri, 13 Feb 1998 14:44:47 -0500

[This is a resend of a message that got lost in distribution during
 the recent PWG server problems.  The original message, however,
 did get stored in the IPP hypermail archives.  This  message,
 however, is slightly different from the hypermail version.]

In the thread on "host-to-device" protocol, Jim Walker wrote:

> One final point about this ubiquity.  It does not do us any good to
> design something that nobody builds.  I do not know much about the
> history of TIPSI, but it seems a valid case in point.  Although it
> is not necessarily a "pretty" protocol, it at least seems to address
> these issues of a host->device protocol (in a transport-independent
> fashion, to boot!).  But nobody built it (sorry, Don), so who cares?

I'd like to put this question on the table:

  What happened to IEEE 1284.1 (TIPSI) such that it was never
  implemented by a large number of printer vendors?

A great number of companies (many of them *major* players) signed
up and produced a very, very useful protocol.  As Jim points out,
TIPSI is a bit ugly in places, but it sure does do a decent job
for a host-to-device network printing protocol.

Here are the top 4 reasons (excuses?) I hear from vendors
as to why they didn't adopt TIPSI:

  1. Microsoft and HP pulled out of the effort quite late in the
     game, citing that "SNMP is the proper method for printer
     management"; therefore, if neither Microsoft nor HP adopt it,
     then I won't either.

  2. Lexmark had an implementation completed as soon as the
     spec was completed, thereby getting a jump on the rest
     of the industry; as a result, we'd be starting off way
     behind them.

  3. It's really only a proprietary protocol from Lexmark.

  4. Without a freely available reference implementation,
     we really can't get rolling on adoption.

Regarding Excuse #1, while it may be viewed that "SNMP is the
One and Only True Way" to manage network devices such as network
printers, the fact is that TIPSI was designed primarily for
PRINTING and not MANAGEMENT.

So, when Microsoft and HP walked away from TIPSI (then called "NPAP"),
the two giants also walked away from the world's first honest
attempt at an open protocol for network printing.  Truly a shame.

Perhaps we can cajole them into reconsidering...

Regarding Excuse #2, Lexmark played the "game" the way it was
supposed to be played, namely, work together with your competitors
and partners for the common good, and implement your solution
as quickly as you can for delivery to the marketplace.  There was
never any kind of "backroom discussions" that allowed Lexmark to
get a lead on anyone else (trust me, I was watching! ;-).

Lexmark just did their job.  And they did it well.  Moreover,
once they found other players were not implementing the joint
spec as quickly, they came in and put almost all of their own
proprietary extensions on the table for inclusion into the
formal spec.

How many vendors do you see doing this, all in the name of getting
a solid, robust specification adopted and deployed??

As for Excuse #3, well that's just par for the course.  Since
Lexmark was the only one to implement TIPSI, the rest of the
world just labelled it as "proprietary", thinking that Lexmark
just got the IEEE to rubber-stamp an already existing protocol
developed by Lexmark internally.  (I have personally heard this
kind of comment over and over again at almost every customer site.)

Now comes Excuse #4...

Do folks really believe this is true?  (I have heard this from
multiple PWG participants, and they know it!)

If a freely available reference implementation of TIPSI were
to become available, would you adopt it?  I'd really like to know,
as my company would be interested in developing it.

Funny, but I don't hear the same kind of "gotta have a free
implementation" by those espousing IPP...  What's different?
(Just curious.)

Incidentally, if anyone is interested in reviewing the TIPSI spec,
please contact me.  Since TIPSI is under IEEE control now, the
normal mechanism is to contact the IEEE and request (and *pay* for)
the IEEE 1284.1 specification.  If you *are* interested in seeing
the spec, please let me know and we can make some arrangements.

If nothing else, TIPSI can serve as an *excellent* starting point
for a network printing protocol, at least in terms of requirements.

Also, for the record, here are pointers to the latest CPAP spec
in various forms:

    ftp://ftp.pwg.org/pub/pwg/cpap/cpap.pdf
    ftp://ftp.pwg.org/pub/pwg/cpap/cpap.ps
    ftp://ftp.pwg.org/pub/pwg/cpap/cpap.ps.gz

Both of these protocols have been "in the field" for several
years now, so the lessons learned (and problems solved) by
either/both of these protocols should not be dismissed during
any discussions we might conduct for a "host-to-device" protocol.

        ...jay

PS: In case anyone was wondering, Underscore is *not* a subsidiary
    of Lexmark International.  In fact, in many respects, we are
    fierce competitors.  We've just learned to cooperate, that's all.
    Credit always belongs to those who deserve it, in any case.

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 13 Feb 1998 16:08:23 -0500

I've waited a long time to respond on this thread but after Jay Martin's
excellent re-cap of  Host-to-Device protocol development history, I
feel the time is right.  I known many of you hear me at various PWG
meetings
when an issue comes up that needs to be addressed, I often chime in
with something like "TIPSI does that" or something to that effect.  Many of
you may think I am attempting to interject a little humor but the reality
is
that I'm being factual.

Please don't be confused about the following and think it is coming from
Geoff (from down-under) but the bottom line is that too many companies
in the printer business are not listening to their customers!  Get this
right -- my customers never told me they wanted TIPSI in their printers.
Maybe that's the problem with conjoint studies and focus groups --
we hear the words of the customers and don't really understand the
root source of those words.  We hear customers say they "want SNMP
management for their printers" or some other technology.  Why?
Because that's what was on PC-Week, or InternetWeek or some
other industry periodical they read last week.  Does this mean they
really want SNMP and think that it will solve all their printer
management and job submission problems.  No way!  The customer
is saying they want control and the only way they can say that so
technical marketing people will listen is to say "SNMP."  Maybe
it is because of some internal religion.  We too often filter
what we hear based on the current religion.  A few years ago
SNMP was the religion.  When we started IPP, HTTP was the
religion.  Now, maybe XML is the religion.  It doesn't matter,
the bottom line is that we are hearing but not listening.

*** Warning self-serving horn tooting ahead ***

Here's the bottom line:

Customer's wanted control.  Customer's wanted to know what
was going on with their printers (instantly -- not some SNMP polling
period away).  Customers want GUI.  Customers wanted ease
of use.  As a result of these needs, several of us began working
on what started as Network Printing Alliance Protocol in 1991
and eventually became IEEE Std 1284.1-1997 last year.

*** End of self-serving horn tooting ***

I've seen several lists of requirements on this thread and have
considered them seriously when compared to the attributes
and features of TIPSI.  With the exception of security, I believe
TIPSI as it exists today meets the vast majority if not all of them.

Do I think the industry needs a robust host to device protocol?  My
answer is no -- we already have one.  If the rest of the printer companies
of the world would deliver what their customer's needed and not just
a clone of what HP has, we wouldn't be having this conversation and
HP wouldn't have 60% market share.  The bottom line is that we all
had a choice.  Many of you participated in the development of
TIPSI but you and your companies decided not to develop and
ship using it.  Now you want to clear the slate and start this whole
thing over again.  Give me a break!  I'm tired of re-inventing
the wheel every couple of years.

If the group "discovers" that TIPSI is a good starting point for a
robust host to device protocol, it won't be a surprise to me.  If there
is a real effort (with HP and Microsoft in the boat) to add security
and update the protocol, I'm all for it and I'll help lead the effort to
open 1284.1 for revision.  But if the decision is that we need to
start all over again with another clean slate then good luck -- I'm
really getting tired of this.

Jay was right on.  His list of 4 excuses was just that "excuses."

Don Wright

Product Manager, Strategic Alliances
Lexmark International
                    - and -
Unashamed TIPSI Advocate