I'm sending this message to see if we can stimulate some discussion on this
subject prior to the 1394PWG meeting in Austin next month.
For the past year we have been meeting to develop a standard to provide the
high functionality transport method for printing over the IEEE 1394
interface. This is 'high functionality' , or 'thick' transport, as opposed
to the 'thin' transport that is being developed by the PWG-C. The
direction that our group has taken has involved reviewing FCP, DFA, SBP-2,
and others, as the lower transport and datalink interface, with something
else as the transport interface. This something else has focused on 1284.4
or on a native 'glue' layer to the underlying datalink.
At this point in time we have apparently narrowed our potential solutions
to the following:
A- 1284.4 with SBP-2
B- New SBP-2 command set with SBP-2
As many of you are aware, I'm primarily in support of option A as the
preferred solution. I'd like to take this opportunity to provide some of
my reasoning and get feedback from you.
My support for this solution is not necessarily a technical reason, but a
market reason. As Greg Shue et al pointed out at the Maui meeting, it is
possible to provide the required functionality by defining a new Command
Set for SBP-2. This would provide a transport solution for 1394 that is
based solely on the SBP-2 protocol. Technically, this is probably a better
solution than option A.
My question is "Is this really the best solution for the market today?".
Many of us have expended great effort in developing the IEEE P1284.4
standard. One of the purposes and goals of the development was to create
a datalink independent transport standard that could be used over the
parallel port and other physical interfaces.
The intent here was to create a standard that would allow a peripheral to
operate over various interfaces without requiring major architectural
changes to the product. In other words, a modular approach to the
peripheral design. A printer or MFP device could be developed to work with
1284.4 over parallel today, and 'easily' adapted to work over 1394
tomorrow. The host application interface may not even know the difference.
I think that this is the primary reasons for choosing option A. It sends a
clear statement to peripheral and OS vendors that 1284.4 is the preferred
transport interface for printer and MFP peripherals. We back this up by
providing solutions for parallel (1284.3) and for 1394. This is not a
stagnant industry and certainly new interfaces will appear in the future.
I think it would be a great service that we provide a clear migration path
between interfaces that do not require redesign of the entire system.
Providing both options may be the result of this effort. I think that
option A should be the preferred one.
I await your responses.
Thanks,
Larry
***************************************************************
Larry A. Stein Phone: (619)292-2742
Warp Nine Engineering Fax: (619)292-8020
Web: http://www.fapo.com
***************************************************************