I still like to provide a same transport for PC software over the other
printer interfaces. Printer manufactures have supported USB, 1284 and .4 for
printers. I believe that no one like to develop software running only with
PWG specific 1394 printer protocol. We need consistency over any printing
devices.
Saying just 1284.4 over SBP-2 may cause some confusions. Have you described
what is inefficient to stack overlapping functionality and tried to remove
it from 1284.4 over SBP-2? Is supporting socket interface included in the
latest proposal? If you have, I am sorry. My manager didn't allow me to
travel to Maui, however I loved to be there. Can you update the latest
status or a meeting memo in Maui? I need catching up you.
By the way, who is Eric? Whom did he contact with in MS? Though I don't own
a storage, I would like to hear the story from him. If someone in MS had
miscommunication with him, I can forward it to proprietary in MS.
Thanks,
Hitoshi
> -----Original Message-----
> From: Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
> Sent: Sunday, February 15, 1998 7:35 PM
> To: Hitoshi Sekine
> Cc: 'PWG-C mailing'; p1284_3@lexmark.com; p1394@pwg.org
> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>
> 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-----
> ??? : Hitoshi Sekine <hitoshis@microsoft.com>
> ?? : '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>
> ?? : 1998?2?16? 7:21
> ?? : 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
> >>
>
>