Subject: Re: P1394> 1284.4 over SBP-2

From: "Eric Anderson" <[email-masked]>
Date: 9 Feb 98 22:33:35 -0800

Hi Larry,

Since you asked, I'll try to politely explain my preference for
solution B: New SBP-2 command set with SBP-2.  I regret that I
can't make a strong argument, because I haven't had the time to
track closely your progress with solution A.  Still, I think
there are compelling reasons to consider solution B.

Recently, the 1394 community had the opportunity to define a
storage protocol for 1394.  The first solution, Tailgate, gave
us essentially an ATA interface bridged over 1394.  Both the
target and the initiator had to operate as if traditional ATA
was the interconnect.  Sure, SBP-2 was present, but only as a
transport, and much of it's potential was wasted.  Tailgate
was supposed to be quick an easy and lead to rapid market
adoption.  What actually happened was quite different.

Microsoft and others realized that adopting this model would
"lock in" ATA for a long time, including long after ATA itself
was dead.  Emulating a dead technology with new technology may
yield short-term savings in implementation, but at the expense of
long-term losses in performance.  Amazingly, reason prevailed,
and Tailgate was abandoned in favor of a pure SBP-2 protocol
for disk drives.  As it turned out, Tailgate vendors quickly
switched to Native Bridge, which still allowed today's drives
to act like 1394 drives, by making them look (from a 1394
point of view) like fully native devices.  As far as I can tell
this switch was not too painful, and now we aren't stuck with
ATA.  Everyone won.

Now we have a similar situation with printers.  1284.4 is a
very well established technology.  Compared to 1394, I think it
would be fair to say that 1284.4 is also a very slow and clumsy
technology (nothing personal!).  Surprise, surprise - the idea
comes up to bundle 1284.4 in SBP-2 because some purported savings
can be had, in the short term.  From what I have seen of how this
works, it is quite inefficient, with lots of unsolicited status
requests and in general lots of hand-holding by the CPU on the
initiator.  This is not what SBP-2 was designed for.

As printer resolutions climb, printer bandwidth rises very
quickly.  Yes, we all still do dull black and white word
processing, but I think you printer vendors will agree that the
exciting (high-margin) areas are in con-tone large-format high-
speed printers - just the sort that need 1394.  Or sparing that,
even consumer-level inkjets now have remarkable resolutions and
consume quite a lot of bandwidth.

Used properly, SBP-2 allows huge data transfers that can proceed
at the pace of the consumer (printer), with no hand-holding by
the host (computer).  Since host systems have 32 or more megs of
RAM today, ideally, printing should proceed with at most one
interrupt per megabyte of data transferred (assuming no errors),
leaving the CPU free to do useful work (like rasterizing).  SBP-2
and OpenHCI make this possible - but only if protocols are designed
with care to avoid needless interruption of the host.

Perhaps I have misunderstood your recent work regarding 1284.4 on
1394 in SBP-2, but I believe that the present plan will have far
more overhead than what I just described.  Specifically, I believe
this overhead comes from carefully emulating 1284.4 rather than
using SBP-2 in it's most natural way.  Over the lifetime of
1394, the cost of that overhead in wasted MIPS and wasted time will
far exceed any possible savings from recycling current protocols
and software.

1394 is far more "future friendly" and scalable than other
interconnects were at their introductions.  That didn't stop
Ethernet, ATA, SCSI, Parallel Port, and the like from living as
useful technologies for one or two decades.  Our goal should be
to make 1394 last at least as long, if not longer.  Portability
of a protocol to new interconnects at the expense of efficiency
doesn't seem valuable to me in this context - in fact, it seems
counter-productive.  The more inefficient the protocol we choose,
the more demand there will be for ever-faster interconnects.  A
well-designed, efficient protocol can last a very long time, and
serve everyone's needs better during that time.

I hope I haven't gone too far overboard here or stepped too hard
on any toes.  To conclude, I want to ask a simple question:  Has
anyone run this idea past Microsoft?  Microsoft killed off
Tailgate, and my guess is that they may have similar feelings
about printing.  Market reality is that we'll all follow whatever
they decide, so it really makes sense to get them involved.

Alas, I can't join you in Austin, but I do welcome your comments
by email.  Please be patient if you ask good (ie hard) questions.

Sincerely,

--------------------------------------
Eric Anderson            [email-masked]
Apple Computer, Inc.      408-974-8187
--------------------------------------

> Hello Everyone,
> 
> 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
> ***************************************************************

---

From: Larry Stein <[email-masked]>
Date: Tue, 10 Feb 1998 07:53:28 -0800

Dear Eric,

Thank you for your comments.  Please see my responses.
For everyone else;  the intent of this thread is to provoke discussion
prior to our next meeting.  Please chime in.

---

From: "Eric Anderson" <[email-masked]>
Date: 10 Feb 98 19:06:26 -0800

Hi Larry,

I never received anything more than what is shown above.  If you
sent comments, please send me another copy.  Thanks!

---

From: Nagasaka Fumio <[email-masked]>
Date: Thu, 12 Feb 1998 15:59:31 +0900

Dear Eric,
Dear Larry,

Please find an attached document which shows issue Eric and myself
had discussed at December 3, 1997.
 <<Generation.PDF>> 
I am writing printer drivers that covers first generation of 1394
printing.
These printer drivers are supporting option A.
<<
A-	1284.4 with SBP-2
B-	New SBP-2 command set with SBP-2
I also prefer to choose option A at least in these couple of years. One
of my reason is market reason same as Larry. Another my reason is
technical reason. As I mentioned before, a target peer which supports
CBT allows initiator peers to send ORBs safely. Any data link layer
which services only one data path has difficulties to support multiple
logical channels. Because, if once one of logical channels had been
stalled, other requests that goes same data path will be stalled.
The CBT set the data link layer free from these difficulties.

However CBT provided by IEEE 1284.4 dose not clear 100 % of
problems. Please show a figure below.
 <<InOrbStalled.PDF>> 
The fourth ORB in this figure will be stalled when ch. #1 of the
target peer does not have any packet to reply. Thus <I> feel
necessity to develop second generation transport layer to 
support SBP-2 printing or completely new idea. However
efforts for standardization will easily take ten to twelve months
if we start to discuss every things from scratch.
I think 1394 PWG shall make first generation protocol with
option A at first.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

		-----Original Message-----
		From:	Larry Stein [SMTP:[email-masked]]
		Sent:	Wednesday, February 11, 1998 12:53 AM
		To:	[email-masked]; Multiple recipients of list
		Cc:	[email-masked]
		Subject:	Re: P1394> 1284.4 over SBP-2

		Dear Eric,

		Thank you for your comments.  Please see my responses.
		For everyone else;  the intent of this thread is to
provoke discussion
		prior to our next meeting.  Please chime in.

---

From: Nagasaka Fumio <[email-masked]>
Date: Fri, 13 Feb 1998 21:47:08 +0900

Hi Greg,

Your opinion persuade me 95%,… I like your opinion.
However I could not agree these points.

Greg Shue wrote:
<<
If “best” is thought of in terms of developers and development effort,
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
developed.
If “best” is thought of in terms of (availability of) OS support,
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
devices.

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?

		-----Original Message-----
		From:	Greg Shue [SMTP:[email-masked]]
		Sent:	Wednesday, February 11, 1998 12:21 PM
		To:	Larry Stein
		Cc:	[email-masked]; [email-masked]
		Subject:	Re: P1394> 1284.4 over SBP-2

		> I await your responses.

		OK, here we go...

		Larry Stein wrote:

		> based solely on the SBP-2 protocol.  Technically, this
is probably a better
		> standard.  One of the purposes and goals of  the
development was to create
		> peripheral design.  A printer or MFP device could be
developed to work with
		> tomorrow.  The host application interface may not even
know the difference.

		As I understood it, the ability for 'a peripheral to
operate over
		various interfaces without requiring major architectural
changes
		to the product' is provided by meeting the specified
transport
		service requirements.  As long as the transport
requirements are
		met, no architectural changes are required of the
product.  Thus,
		the transport layers are all modular with respect to the
product.
		(I think this is also why the PWG has not tried to
eliminate a
		TCP/IP printing solution.  :-)

		The main difference between options A and B is whether
multiple
		services are made available through a 1284.4 MUX layer,
or
		through a combination of Unit Directories and Logical
Unit
		Numbers.  The command set features needed for a combined
		1284.4/SBP-2 solution are essentially identical as for
an
		SBP-2 only solution (as shown below).

		  In order to provide a combined SBP-2/1284.4 solution,
an
		  SBP-2 command set must be provided which meets the
Data Link
		  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
a whole
		    R3) Asynchronous Operation - no polling shall be
required.

		  In order to map this within SBP-2, then the command
set must
		  provide (at least) the following features:

		    F1) Transient link interruption support
			  (to support R2 and R3)
		    F2) Non-transient link loss indication  (to support
F1)
		    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
access
			 control (to support R2, R3, and F1)

		    F8) Standard mechanism for indicating existence of
1284.4
			 peer (to support R1)

		    So, any of these features which are common with an
SBP-2 only
		    solution are outside the scope of concern here.
(For the
		    unfamiliar, they all are provided in the (very
rough) SBP-2
		    only proposal presented at the January PWG 1394
meeting.)

		These features are also those required for an SBP-2 only
solution.
		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,
because "best"
		is rather subjective.  What's "best" for a customer
might not be
		"best" for a developer, and that might not be "best" for
a
		technology, which are all indirectly related to what is
"best"
		for the market.  I tried to identify above what are not
areas of
		tradeoffs between the two options so that we can look at
what are.

		If "best" is thought of in terms of market, then (I
suppose)
		supportability and deployment of the solution(s) matter
the most,
		because the 'market' has almost no history.  There
really is no
		legacy issue which makes either choice A or choice B
preferred,
		even though there are "legacy" printing solutions which
will need
		to be supported (i.e.  AVC, IP1394).  So, each of the
following
		areas become signficant:

		If "best" is thought of in terms of providing the
transport
		services outlined by the requirements, then there is no
		signficant difference between the SBP-2 only solution or
the
		combined solution.

		If "best" is thought of in terms of developers and
development
		effort, 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 developed.

		If "best" is thought of in terms of (availability of) OS
support,
		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 "best" is thought of in terms of product cost, then
the SBP-2
		only solution is preferred because it has fewer layers.

		If "best" is thought of in terms of performance, then
the SBP-2
		only solution is preferred because it isn't limited to
64-KByte
		packets.

		If "best" is thought of in terms of 1394 bus usage, then
the
		SBP-2 only solution is preferred because it doesn't have
the CBT
		crediting traffic of 1284.4.

		If "best" is thought of in terms of compliance
testability, then
		the SBP-2 only solution is preferred because it is
simpler and
		has fewer layers.

		If "best" is thought of in terms of availability
customer
		solutions, then the SBP-2 only solution is preferred
because of
		it's smaller footprint (which makes it more attractive
to
		integrate into more devices) and it's spreading use for
varying
		types of services on 1394.

		> I think that this is the primary reasons for choosing
option A.  It sends a
		> 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.

		Unfortunately, that message of 1284.4 being "the
preferred
		transport interface for printers" has been lost in the
shuffle.
		There are (currently) four transport protocols being
defined on
		1394 for printing.  These are:

		  + AVC (for video snapshot)
		  + DPP (for non-PC device-to-device)
		  + PWG 1394 solution(s) (being discussed)
		  + IP1394

		I also haven't seen it get embraced for standardization
on USB,
		where hardware limitations and lack of a multiplexing
transport
		protocol solution identify a hole which 1284.4 can fill.

		When this is added to (Apple's) Eric Anderson's thoughts
of:

		  - Emulating a dead technology with new technology may
yield
		    short-term savings in implementation, but at the
expense of
		    long-term losses in performance.  (philisophical)

		  - Amazingly, reason prevailed, and Tailgate was
abandoned in
		    favor of a pure SBP-2 protocol for disk drives.
(historical)

		  - From what I have seen of how this (1284.4 over
SBP-2) works,
		    it is quite inefficient, with lots of unsolicited
status
		    requests and in general lots of hand-holding by the
CPU on the
		    initiator.  This is not what SBP-2 was designed for.
(perceptual)

		  - Used properly, SBP-2 allows huge data transfers that
can proceed
		    at the pace of the consumer (printer), with no
hand-holding by
		    the host (computer)... SBP-2 and OpenHCI make this
possible - but
		    only if protocols are designed with care to avoid
needless
		    interruption of the host.  (practical)

		  - 1394 is far more "future friendly" and scalable than
other
		    interconnects were at their introductions...  The
more inefficient
		    the protocol we choose, the more demand there will
be for
		    ever-faster interconnects.  A well-designed,
efficient protocol
		    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
anyone run
		    this idea past Microsoft?  Microsoft killed off
Tailgate, and
		    my guess is that they may have similar feelings
about printing.
		    Market reality is that we'll all follow whatever
they decide,
		    so it really makes sense to get them involved.
(REALISTIC!!)

		And (from a previous posting of Eric's):

		 -  Microsoft says that their treatment of printers will
be
		    different.  They will only login to printers and
other shared
		    devices when they actually want to use the printer.
So a printer
		    with only one login could be shared by several
Windows systems.
		    Apple plans to do the same thing for printers using
SBP-2.

		And the most quotable quote from the January 98 PWG 1394
meeting:

		  "Every protocol looks light until it's implemented."

		Given all of this, I am compelled to support option B.

		-- 
		Greg Shue
		Hewlett-Packard Company
		Office Products
Division			[email-masked]
	
----------------------------------------------------------------

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 13 Feb 1998 06:08:57 -0800

If we want to keep the application programming interface consistent
across all different kind of link types, then I think a socket interface
is the best way to do this. Note that this application interface only
provides access to a "transport" stack. The actual application protocol
used (DPP, IPP, 1284.1, etc.) would still be done by the application.

And if we want to use a socket interface as the common transport
interface for applications, this socket interface would support all of
the layering models that have been proposed thus far, including, but not
limited to:
				1284.4 over SBP-2
				SBP-2 over transaction layer (OHCI,
etc.)
				1284.4 over 1284.3
				TCP/IP over ethernet
				TCP/IP over 1394

Note that the SBP-2 over transaction layer option would also support DPP
over socket interface as well.

My point from all of this is that for the layering models discussed so
far, we don't have to worry about providing a common API for
applications. So we can keep our discussion focused on relevant
technical transport issues.

Randy

	-----Original Message-----
	From:	Nagasaka Fumio [SMTP:[email-masked]]
	Sent:	Friday, February 13, 1998 4:47 AM
	To:	Greg Shue; Larry Stein
	Cc:	[email-masked]; [email-masked]; PWG-C mailing
	Subject:	RE: P1394> 1284.4 over SBP-2

	Hi Greg,

	Your opinion persuade me 95%,? I like your opinion.
	However I could not agree these points.

	Greg Shue wrote:
	<<
	If ?best? is thought of in terms of developers and development
effort,
	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
	developed.
	If ?best? is thought of in terms of (availability of) OS
support,
	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
	devices.

	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). 

			-----Original Message-----
			From:	Greg Shue [SMTP:[email-masked]]
			Sent:	Wednesday, February 11, 1998 12:21 PM
			To:	Larry Stein
			Cc:	[email-masked]; [email-masked]
			Subject:	Re: P1394> 1284.4 over SBP-2

			OK, here we go...

			Larry Stein wrote:

			> At this point in time we have apparently
narrowed our
	potential solutions
			> 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 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
	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
			> a datalink independent transport standard that
could
	be used over the
			> 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
	developed to work with
			> 1284.4 over parallel today, and 'easily'
adapted to
	work over 1394
	know the difference.

			As I understood it, the ability for 'a
peripheral to
	operate over
			various interfaces without requiring major
architectural
	changes
			to the product' is provided by meeting the
specified
	transport
			service requirements.  As long as the transport
	requirements are
			met, no architectural changes are required of
the
	product.  Thus,
			the transport layers are all modular with
respect to the
	product.
			(I think this is also why the PWG has not tried
to
	eliminate a
			TCP/IP printing solution.  :-)

			The main difference between options A and B is
whether
	multiple
			services are made available through a 1284.4 MUX
layer,
	or
			through a combination of Unit Directories and
Logical
	Unit
			Numbers.  The command set features needed for a
combined
			1284.4/SBP-2 solution are essentially identical
as for
	an
			SBP-2 only solution (as shown below).

			  In order to provide a combined SBP-2/1284.4
solution,
	an
			  SBP-2 command set must be provided which meets
the
	Data Link
			  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
	a whole
			    R3) Asynchronous Operation - no polling
shall be
	required.

			  In order to map this within SBP-2, then the
command
	set must
			  provide (at least) the following features:

			    F1) Transient link interruption support
				  (to support R2 and R3)
			    F2) Non-transient link loss indication  (to
support
	F1)
			    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
	access
				 control (to support R2, R3, and F1)

			    F8) Standard mechanism for indicating
existence of
	1284.4
				 peer (to support R1)

			    So, any of these features which are common
with an
	SBP-2 only
			    solution are outside the scope of concern
here.
	(For the
			    unfamiliar, they all are provided in the
(very
	rough) SBP-2
			    only proposal presented at the January PWG
1394
	meeting.)

			These features are also those required for an
SBP-2 only
	solution.
			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,
	because "best"
			is rather subjective.  What's "best" for a
customer
	might not be
			"best" for a developer, and that might not be
"best" for
	a
			technology, which are all indirectly related to
what is
	"best"
			for the market.  I tried to identify above what
are not
	areas of
			tradeoffs between the two options so that we can
look at
	what are.

			If "best" is thought of in terms of market, then
(I
	suppose)
			supportability and deployment of the solution(s)
matter
	the most,
			because the 'market' has almost no history.
There
	really is no
			legacy issue which makes either choice A or
choice B
	preferred,
			even though there are "legacy" printing
solutions which
	will need
			to be supported (i.e.  AVC, IP1394).  So, each
of the
	following
			areas become signficant:

			If "best" is thought of in terms of providing
the
	transport
			services outlined by the requirements, then
there is no
			signficant difference between the SBP-2 only
solution or
	the
			combined solution.

			If "best" is thought of in terms of developers
and
	development
			effort, 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
developed.

			If "best" is thought of in terms of
(availability of) OS
	support,
			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 "best" is thought of in terms of product
cost, then
	the SBP-2
			only solution is preferred because it has fewer
layers.

			If "best" is thought of in terms of performance,
then
	the SBP-2
			only solution is preferred because it isn't
limited to
	64-KByte
			packets.

			If "best" is thought of in terms of 1394 bus
usage, then
	the
			SBP-2 only solution is preferred because it
doesn't have
	the CBT
			crediting traffic of 1284.4.

			If "best" is thought of in terms of compliance
	testability, then
			the SBP-2 only solution is preferred because it
is
	simpler and
			has fewer layers.

			If "best" is thought of in terms of availability
	customer
			solutions, then the SBP-2 only solution is
preferred
	because of
			it's smaller footprint (which makes it more
attractive
	to
			integrate into more devices) and it's spreading
use for
	varying
			types of services on 1394.

	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.
	clear migration path
			> between interfaces that do not require
redesign of the
	entire system.

			Unfortunately, that message of 1284.4 being "the
	preferred
			transport interface for printers" has been lost
in the
	shuffle.
			There are (currently) four transport protocols
being
	defined on
			1394 for printing.  These are:

			I also haven't seen it get embraced for
standardization
	on USB,
			where hardware limitations and lack of a
multiplexing
	transport
			protocol solution identify a hole which 1284.4
can fill.

			When this is added to (Apple's) Eric Anderson's
thoughts
	of:

			  - Emulating a dead technology with new
technology may
	yield
			    short-term savings in implementation, but at
the
	expense of
			    long-term losses in performance.
(philisophical)

			  - Amazingly, reason prevailed, and Tailgate
was
	abandoned in
			    favor of a pure SBP-2 protocol for disk
drives.
	(historical)

			  - From what I have seen of how this (1284.4
over
	SBP-2) works,
			    it is quite inefficient, with lots of
unsolicited
	status
			    requests and in general lots of hand-holding
by the
	CPU on the
			    initiator.  This is not what SBP-2 was
designed for.
	(perceptual)

			  - Used properly, SBP-2 allows huge data
transfers that
	can proceed
			    at the pace of the consumer (printer), with
no
	hand-holding by
			    the host (computer)... SBP-2 and OpenHCI
make this
	possible - but
			    only if protocols are designed with care to
avoid
	needless
			    interruption of the host.  (practical)

			  - 1394 is far more "future friendly" and
scalable than
	other
			    interconnects were at their introductions...
The
	more inefficient
			    the protocol we choose, the more demand
there will
	be for
			    ever-faster interconnects.  A well-designed,
	efficient protocol
			    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
	anyone run
			    this idea past Microsoft?  Microsoft killed
off
	Tailgate, and
			    my guess is that they may have similar
feelings
	about printing.
			    Market reality is that we'll all follow
whatever
	they decide,
			    so it really makes sense to get them
involved.
	(REALISTIC!!)

			 -  Microsoft says that their treatment of
printers will
	be
			    different.  They will only login to printers
and
	other shared
			    devices when they actually want to use the
printer.
	So a printer
			    with only one login could be shared by
several
	Windows systems.
			    Apple plans to do the same thing for
printers using
	SBP-2.

			And the most quotable quote from the January 98
PWG 1394
	meeting:

			  "Every protocol looks light until it's
implemented."

			Given all of this, I am compelled to support
option B.