Your opinion persuade me 95%,$B!D(J I like your opinion.(J
However I could not agree these points.
Greg Shue wrote:
If $B!H(Jbest$B!I(J is thought of in terms of developers and development effort,(J
then there is no significant difference between providing the SBP-2 only
solution or the SBP-2 portion of a combined solution. There will be
additional effort for a combined solution if a 1284.4 driver needs to be
If $B!H(Jbest$B!I(J is thought of in terms of (availability of) OS support,(J
then the SBP-2 only solution is preferred because a greater portion
of the total solution already is provided by or is committed to
by OS vendors.
If we choose 1284.4 as transport layer in PC printing architecture,
we can use same transport layer to cover USB, 1394 and conventional
parallel port. And if we adopt socket API on 1284.4 service, then we
can use same interface for any local devices and for any network
This feature greatly decrease development efforts to make protocol
stack in PC printing area. And it would provide better usability even
for end users.
If we choose new transport for SBP-2/1394 stack, then we need to
develop different middle device driver to cover rest of other I/O(s).
How do you think this point?
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to email@example.com
From: Greg Shue [SMTP:firstname.lastname@example.org]
Sent: Wednesday, February 11, 1998 12:21 PM
To: Larry Stein
Cc: email@example.com; P1284_3@lexmark.com
Subject: Re: P1394> 1284.4 over SBP-2
> I await your responses.
OK, here we go...
Larry Stein wrote:
> At this point in time we have apparently narrowed our
> 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
> 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.
As I understood it, the ability for 'a peripheral to
various interfaces without requiring major architectural
to the product' is provided by meeting the specified
service requirements. As long as the transport
met, no architectural changes are required of the
the transport layers are all modular with respect to the
(I think this is also why the PWG has not tried to
TCP/IP printing solution. :-)
The main difference between options A and B is whether
services are made available through a 1284.4 MUX layer,
through a combination of Unit Directories and Logical
Numbers. The command set features needed for a combined
1284.4/SBP-2 solution are essentially identical as for
SBP-2 only solution (as shown below).
In order to provide a combined SBP-2/1284.4 solution,
SBP-2 command set must be provided which meets the
requirements spelled out for 1284.4. These are:
R1) Register/Unregister transport layer with the
Data Link layer
R2) Packet Data Transfer - error free, in order, as
R3) Asynchronous Operation - no polling shall be
In order to map this within SBP-2, then the command
provide (at least) the following features:
F1) Transient link interruption support
(to support R2 and R3)
F2) Non-transient link loss indication (to support
F3) Extended SBP-2 Access Control to the transport
interface (to support F1)
F4) SBP-2 ORB execution model for packet transfers
(to support R2 and R3)
F5) Encapsulating of 1284.4 packets into ORBs
(to support R2)
F6) Policy to determine maximum DL packet size
(to support R2 and F1)
F7) Policy for how 1284.4 dialogue maps into SBP-2
control (to support R2, R3, and F1)
F8) Standard mechanism for indicating existence of
peer (to support R1)
So, any of these features which are common with an
solution are outside the scope of concern here.
unfamiliar, they all are provided in the (very
only proposal presented at the January PWG 1394
These features are also those required for an SBP-2 only
Since these are in common, they _don't_ affect the
choice of option A
vs. option B.
I can't give an answer to Larry's question directly,
is rather subjective. What's "best" for a customer
might not be
"best" for a developer, and that might not be "best" for
technology, which are all indirectly related to what is
for the market. I tried to identify above what are not
tradeoffs between the two options so that we can look at
If "best" is thought of in terms of market, then (I
supportability and deployment of the solution(s) matter
because the 'market' has almost no history. There
really is no
legacy issue which makes either choice A or choice B
even though there are "legacy" printing solutions which
to be supported (i.e. AVC, IP1394). So, each of the
areas become signficant:
If "best" is thought of in terms of providing the
services outlined by the requirements, then there is no
signficant difference between the SBP-2 only solution or
If "best" is thought of in terms of developers and
effort, then there is no significant difference between
the SBP-2 only solution or the SBP-2 portion of a
solution. There will be additional effort for a
solution if a 1284.4 driver needs to be developed.
If "best" is thought of in terms of (availability of) OS
then the SBP-2 only solution is preferred because a
of the total solution already is provided by or is
by OS vendors.
If "best" is thought of in terms of product cost, then
only solution is preferred because it has fewer layers.
If "best" is thought of in terms of performance, then
only solution is preferred because it isn't limited to
If "best" is thought of in terms of 1394 bus usage, then
SBP-2 only solution is preferred because it doesn't have
crediting traffic of 1284.4.
If "best" is thought of in terms of compliance
the SBP-2 only solution is preferred because it is
has fewer layers.
If "best" is thought of in terms of availability
solutions, then the SBP-2 only solution is preferred
it's smaller footprint (which makes it more attractive
integrate into more devices) and it's spreading use for
types of services on 1394.
> 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
Unfortunately, that message of 1284.4 being "the
transport interface for printers" has been lost in the
There are (currently) four transport protocols being
1394 for printing. These are:
+ AVC (for video snapshot)
+ DPP (for non-PC device-to-device)
+ PWG 1394 solution(s) (being discussed)
I also haven't seen it get embraced for standardization
where hardware limitations and lack of a multiplexing
protocol solution identify a hole which 1284.4 can fill.
When this is added to (Apple's) Eric Anderson's thoughts
- Emulating a dead technology with new technology may
short-term savings in implementation, but at the
long-term losses in performance. (philisophical)
- Amazingly, reason prevailed, and Tailgate was
favor of a pure SBP-2 protocol for disk drives.
- From what I have seen of how this (1284.4 over
it is quite inefficient, with lots of unsolicited
requests and in general lots of hand-holding by the
CPU on the
initiator. This is not what SBP-2 was designed for.
- Used properly, SBP-2 allows huge data transfers that
at the pace of the consumer (printer), with no
the host (computer)... SBP-2 and OpenHCI make this
possible - but
only if protocols are designed with care to avoid
interruption of the host. (practical)
- 1394 is far more "future friendly" and scalable than
interconnects were at their introductions... The
the protocol we choose, the more demand there will
ever-faster interconnects. A well-designed,
can last a very long time, and serve everyone's
needs better during
that time. (consequential)
- To conclude, I want to ask a simple question: Has
this idea past Microsoft? Microsoft killed off
my guess is that they may have similar feelings
Market reality is that we'll all follow whatever
so it really makes sense to get them involved.
And (from a previous posting of Eric's):
- Microsoft says that their treatment of printers will
different. They will only login to printers and
devices when they actually want to use the printer.
So a printer
with only one login could be shared by several
Apple plans to do the same thing for printers using
And the most quotable quote from the January 98 PWG 1394
"Every protocol looks light until it's implemented."
Given all of this, I am compelled to support option B.