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