Eric, Thank you for forwarding your mail. It is what I needed to know.
Though I don't think we can throw an official comment to this public mail
alias, we can do our best to work with the industry together.
Using Sbp-2 is fine with us. I can easily implement printing stack at the
top of SBP-2. It is also reasonable with Printers. It seems that many people
in PWG can agree it.
I haven't personally decided which "option" is better since I haven't done
any technical investigation of 1284.4 over SBP-2. But the reason why I like
it is that we can provide same interfaces to any printing interfaces such as
1284, USB and 1394. Some people (Randy and ...) mentioned to define Socket
interface at the top of the layer. If it can be implemented over any
printing interfaces, it may be enough. I am particular about "SBP-2" but not
so particular about "1284.4 over SBP-2".
Thanks,
Hitoshi
> -----Original Message-----
> From: George Chrysanthakopoulos
> Sent: Monday, February 16, 1998 5:39 PM
> To: Hitoshi Sekine; 'Eric Anderson'
> Cc: John Nels Fuller
> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>
> Hi i am very familiar with the hole tailgate deal since i made my best to
> get rid of it. Our intentions for printing are the same as for storage.
> Use a protocol/command set that makes sense over 1394. Sbp2 is used for
> both, same driver same stack...
>
> For storage we are using MMC2/RBC.
> For printing i had no intention to support 1284.4 by making any special
> adjustments to the 1394/sbp2 stack. If somebody managed to attach 1284.4
> on top then thats fine ( although i agree its not the preferred method)
>
> The current plan is to use the scsi command set over sbp2, to talk to
> scanners/printers. If the scsi command set is not adequete( or too
> bloated), then we neeed to go towards that direction(just like RBC). Right
> now however using SCSI will make existing scanner technology and hopefully
> printers come faster in the market using the sbp/1394.
>
> i have made our intentions clear to the printing/scanner vendors i have
> been in touch so far..
>
> thanx
> g
>
> -----Original Message-----
> From: Hitoshi Sekine
> Sent: Monday, February 16, 1998 5:29 PM
> To: John Nels Fuller; George Chrysanthakopoulos
> Cc: 'Eric Anderson'
> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>
> George and John,
>
> Have you spoke to Eric at Apple? Are you aware of the story of Tailgate?
>
> thanks,
> hitoshi
>
> -----Original Message-----
> From: Eric Anderson [SMTP:ewa@apple.com]
> Sent: Monday, February 16, 1998 2:45 AM
> To: Hitoshi Sekine
> Cc: p1284_3@lexmark.com; p1394@pwg.org; pp1394@cpdc.canon.co.jp
> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>
> Hello Sekine-san,
>
> I am "Eric". I am the FireWire Software lead at Apple Computer.
>
> You wrote:
> "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."
>
> Do you speak officially for Microsoft in Redmond? Is this a policy
> statement that Microsoft will support 1284.4 over 1394 instead of
> a pure SBP-2 native printer protocol? This would be very different
> from Microsoft's position about Tailgate. The 1394 team in Redmond
> has been quiet on this subject, so an official response would help.
>
> Since you did not recognize my name, perhaps you did not see my
> original message. A copy is attached below.
>
> --------------------------------------
> Eric Anderson ewa@apple.com
> Apple Computer, Inc. 408-974-8187
> --------------------------------------
>
> ============
> == This letter was sent to p1394@pwg.org and P1284_3@lexmark.com
> == by Eric Anderson (ewa@apple.com) on 98.02.09:
>
> 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.
> ============
> > Nakamura-san,
> >
> > 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
> > > >>
> > >
> > >
> >
>
>
>
>
>