P1394 Mail Archive: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

Atsushi Nakamura (atsnaka@mxa.mesh.ne.jp)
Mon, 16 Feb 1998 12:34:52 +0900

For PWG printing,
We will have to decide whether not we use 1284.4 or not,
but in any case, it is inefficient to stack overlapping
functionality.
My choices would be either :

1) 1284.4 - "glue"- 1394
2) "glue"or cmd set - SBP-2- 1394
3) "glue"or cmd set - other transport(thin?)-1394

I am yet uncertain which is the best( maybe 2) or 3) ),
but I DO have a opinion that in any case :
1284.4 over SBP-2
is not my choice, because in this case;

>Sure, SBP-2 was present, but only as a
>transport, and much of it's potential was wasted.

would happen. (same for 1284.4)
Is using 1284.4 our first priority, or is using SBP-2 our
first priority ? (or something else? )(or using both !?)

P.S I would like to refer to Eric's comment about the 1394 disks
again.
>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.

I think this is the same situation with 1284.4 (as ATA) and
SBP-2 (or IP,Thin.... )

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

Let's not repeat history....

-------------------------------------------------
Atsushi Nakamura
BJ Printing Technology 22
Canon Inc.
-------------------------------------------------

-----Original Message-----
$B:9=P?M(B : Hitoshi Sekine <hitoshis@microsoft.com>
$B08@h(B : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen Holmstead'
<stephen@hpb16977.boi.hp.com>; 'Toru Ueda' <ueda@slab.tnr.sharp.co.jp>;
Turner, Randy <rturner@sharplabs.com>
CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org <p1394@pwg.org>;
'PWG-C mailing' <pp1394@cpdc.canon.co.jp>; 'p1284_3@lexmark.com'
<p1284_3@lexmark.com>
$BF|;~(B : 1998$BG/(B2$B7n(B16$BF|(B 7:21
$B7oL>(B : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes

>
>I love a symmetrical transport also. PC Printing has supported 1284, USB
and
>1394 soon. If you considers a symmetrical transport for 1284, USB and 1394
>(and IP), it will be great for us. To redesign PC software only for a new
>1394 print transport will be tough. I don't mean to recommend different
>solutions between PWG-C and PWG. We need to get our priorities right. Not
to
>confuse PC software industry is my first priority.
>
>I personally understand that 1284.4 may be a bridge over those local
>interfaces and familiar with an IP printer.
>
>Hitoshi Sekine
>
>
>> -----Original Message-----
>> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
>> Sent: Saturday, February 14, 1998 9:04 PM
>> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
>> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
>> 'p1284_3@lexmark.com'; Hitoshi Sekine
>> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>>
>> Dear Stephen,
>>
>> Your opinion bring us back to December 1996. Actually we started from
>> this point.
>>
>> I would like to list up existing standards and some proposals here.
>>
>> Transaction architecture:
>> -------------------------------------------------------------------------
-
>> ----------------
>> IEEE 1394 | Memory Bus
>> -------------------------------------------------------------------------
-
>> ----------------
>> SBP-2 | Memory Bus
>> DPP | Stream (PWG-C / Toru Ueda)
>> TCP | Stream
>> DFA | Stream (PWG / Alan C. Berkema)
>> 1284.4 | no definition
>> -------------------------------------------------------------------------
-
>> ----------------
>>
>> Transaction style:
>> -------------------------------------------------------------------------
-
>> ----------------
>> IEEE 1394 | push and pull, symmetrical
>> -------------------------------------------------------------------------
-
>> ----------------
>> SBP-2 | pull
>> DPP | push, symmetrical
>> TCP | push, symmetrical (may implement passive open)
>> DFA | push, symmetrical
>> 1284.4 | push control, symmetrical
>> -------------------------------------------------------------------------
-
>> ----------------
>>
>> Please correct if I had overlooked something or I am missing some points.
>>
>> Stephen wrote:
>> <<
>> requirements). I would HATE to have to make a printer that implemented
>> two different transports for PWG and PWG-C printing. I think most
>> printer manufacturers would agree.
>> >>
>>
>> No.
>> Due to some market reasons, printer manufactures are required
>> to support USB, conventional parallel port, 1394 and Macintosh serial
>> interface. However Digital Camera (one of typical consumer imaging
>> device) does not support parallel port. Thus for some consumer
>> device manufactures, it is meaning less to have a solution which
>> provide common protocol stack to cover various existing interface.
>>
>> If PWG and PWG-C shall have same solution, I think we shall
>> have only one "Printer Working Group". However many Japanese
>> companies could not agree with this plan. They might have their own
>> reasons. And I think we ought to pay consideration for them.
>> --------------------------------------------
>> -------------------------------
>> Fumio Nagasaka
>> Epson Software Development Laboratory Inc.
>> Tel +81 268 25 4111, Fax +81 268 25 4627
>> E-mail to nagasaka.fumio@exc.epson.co.jp
>>
>> -----Original Message-----
>> From: Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
>> Sent: Saturday, February 14, 1998 12:59 PM
>> To: 'Toru Ueda'; Turner, Randy
>> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
>> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>>
>> I agree with Toru that we NEED a symmetrical transport. I really don't
>> care which option (A or B) is used, as long as we can provide a
>> symmetrical connection. In fact, that was one of the PWG transport
>> requirements from that start, but it just seems that we have accepted a
>> transport (SBP-2) that isn't symmetrical and we are calling it good.
>> The PWG-C also needs a symmetrical transport. I would love to have the
>> same transport for the PWG and PWG-C (since they both have the same
>> requirements). I would HATE to have to make a printer that implemented
>> two different transports for PWG and PWG-C printing. I think most
>> printer manufacturers would agree.
>>
>> Greg Shue said that he made a proposal to the January PWG that would
>> extend SBP-2 so that it was symmetrical (at least that is what I
>> understand--I may be way off here). If so, that would be great. I have
>> not been able to find any minutes from the PWG since Dec 97 (anyone got
>> some?).
>>
>> 1394 could really use a commonly accepted symmetrical transport layer.
>> If that's 1284.4, great. If that's a modified SBP-2, great. If that's
>> TCP/IP, great. If that's DPP's Thin Protocol, great.
>>
>> Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
>>
>> Stephen Holmstead
>>