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
>
> > -----Original Message-----
> > From: Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
> > Sent: Friday, February 13, 1998 5:45 AM
> > To: Turner, Randy
> > Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> > Subject: Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM
> > sizes
> >
> >
> > I don't want to make any confusion about PC printing protocol. This is
> > only for your information.
> >
> > >From consumer device point of view, "symmetrical" is the essential
> > feature of the protocol.
> > For example, a digital still camera wants to send its image data to
> > printers. Also the same camera wants to receive image data from the
> > other still cameras. We want to use the same protocol for both use.
> >
> > These are three essential features for consumer device.
> >
> > 1) Bi-directional
> > Each side can send and receive data.
> > SBP2 supports bi-directional feature.
> >
> > 2) "True" bi-directional
> > Each side can send and receive data at any time.
> > Alan's architecture supports "true" bi-directional feature by using
> > transmit buffer, receive buffer and unsolicited status.
> >
> > 3) Symmetrical
> > Each side has the same architecture.
> > This is completely different from bi-directional issue.
> >
> > Consumer device needs these three features and the protocol must be
> > simple.
> >
> > If SBP2 implementation needs 30K for initiator and target, it might be
> > difficult to use it for consumer device.
> >
> > Toru Ueda
> > Software labs.
> > Sharp Corp.
> >
> > On Wed, 11 Feb 1998 08:35:10 -0800
> > "Turner, Randy" <rturner@sharplabs.com> wrote:
> >
> > >
> > >
> > > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> > > maybe, but I hadn't seen the chip set feature in the brochure for
> > > "chip-level SBP-2 support".
> > >
> > > Also, since 1394 is a peer-to-peer interface, anyone developing a
> > > peer-to-peer device (like the majority of the Japanese electronics
> > > industry), would have to essentially duplicate the functionality of
> > > SBP-2 initiator and target, whether they actually use SBP-2 to do
> > this,
> > > or some other (potentially proprietary) method for implementing
> > > peer-to-peer functionality.
> > >
> > > Randy
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> > > Sent: Wednesday, February 11, 1998 8:30 AM
> > > To: 'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> > > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
> > > ROM sizes
> > >
> > > My experiences in the past is that combining target AND
> > > initiator
> > > functions into a single device is VERY difficult. The
> > > complexity of the
> > > state tables and ambiguities that can arise make it very
> > > difficult.
> > > Also, I don't believe any of the chip manufacturers support
> > > SBP-2 for
> > > both target and initiator. In my opinion, it's NOT just a
> > > matter of
> > > adding the 15K for the target and 15K for the initiator. The
> > > target and
> > > initiator have vastly different functions. Designing a model
> > > that did
> > > both (well) would be a challenge. It was problems like this
> > > that fueled
> > > many of the AEN (asynchronous event notification) debates.
> > >
> > > Stephen
> > >
> > > > -----Original Message-----
> > > > From: Turner, Randy [SMTP:rturner@sharplabs.com]
> > > > Sent: Monday, February 09, 1998 1:03 PM
> > > > To: 'Brian Batchelder'; p1394@pwg.org
> > > > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
> > > ROM sizes
> > > >
> > > >
> > > > I am very interested in the combined target/initiator
> > > footprint as
> > > > well.
> > > >
> > > > Thx
> > > >
> > > > Randy
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Brian Batchelder [SMTP:brianb@vcd.hp.com]
> > > > Sent: Monday, February 09, 1998 9:37 AM
> > > > To: p1394@pwg.org
> > > > Subject: Re: P1394> Rough SBP-2 & IP1394 core
> > > component
> > > > ROM sizes
> > > >
> > > > At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> > > >
> > > > [snip]
> > > >
> > > > >I approached them about sharing some rough estimates of
> > > code
> > > > size
> > > > >for the IP1394 glue, SBP-2 target and initiator, and
> > > 1394 bus
> > > > >manager modules to get a feel for how "heavy" the
> > > protocol
> > > > >implementations really are. They graciously shared the
> > > flowing
> > > > >estimates with us, and certainly deserve our thanks.
> > > Since the
> > > > >technology is still being developed, these
> > > implementations are
> > > > >certainly going to be tuned and the numbers will change
> > > a
> > > > little
> > > > >bit.
> > > > >
> > > > > Component Rough ROM size (KBytes)
> > > > > --------- -----------------------
> > > > > SBP-2 initiator core 15 +/- 5
> > > > > SBP-2 target core 15 +/- 5 (incl. Mgmt+Fetch
> > > agent,
> > > > no exec agent)
> > > >
> > > > Any idea how big a combined SBP-2 target/initiator would
> > > be?
> > > > 15-30K? ;-)
> > > >
> > > > [snip]
> > > >
> > > > Brian
> > > >
> > > >
> > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > ~
> > > > Brian Batchelder | Hewlett-Packard |
> > > > mailto:brianb@vcd.hp.com
> > > > Connectivity Futurist | 1115 SE 164th Ave. | Phone:
> > > (360)
> > > > 212-4107
> > > > DeskJet Printers | Vancouver, WA 98684 | Fax:
> > > (360)
> > > > 212-4227
> > >