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: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------