I would like very much to be able to write 1394 multifunction apps
according to the Winsock 2 specification. I am coming to the conclusion
that I would like to see one of the following two architectures to be
used:
1. Application over SBP-2 over 1394 transaction layer
(OHCI, etc.)
2. Application over 1284.4 over 1394 transaction layer
(OHCI, etc.)
In my opinion we should have a goal of maintaining a single link layer
protocol for both THIN and THICK solutions (if there is a THICK
solution). This means that for DPP solutions I would like to see us use
SBP-2, both initiator and target. If the PWG-C designs a lighter weight
link layer protocol (lighter than SBP-2), then I think we should attempt
to standardize this protocol and use it.
You will notice that I have left out the option of 1284.4 over SBP-2
because I agree with the overall sentiment that there is significant
overlap between what the two protocols offer. If there is a desire to
use 1284.4, then mapping 1284.4 directly over the 1394 transaction layer
is a natural fit. If we want to use SBP-2, then there is really no need
to use 1284.4 and we can still provide the same API to application
software.
In my opinion, a target-only or initiator-only implementation of SBP-2
is not very interesting given the peer-to-peer capabilities of the 1394
interface. Which means that if I need true peer-to-peer functionality,
then I will have to create yet again another new link layer protocol,
and I would rather solve the link layer protocol problem once. I have
not seen a technical reason so far on the DL that would adequately
explain why we cannot settle on a single, peer-to-peer link layer
protocol for 1394.
As far as the "application" specified in options 1 and 2 above, I'm
assuming this would either be DPP, 1284.1, or some other application
layer protocol.
Randy
-----Original Message-----
From: Hitoshi Sekine [SMTP:hitoshis at MICROSOFT.com]
Sent: Sunday, February 15, 1998 10:00 PM
To: 'atsnaka at mxa.mesh.ne.jp'
Cc: 'p1284_3 at lexmark.com'; 'p1394 at pwg.org';
'pp1394 at cpdc.canon.co.jp'
Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
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 at mxa.mesh.ne.jp]
> Sent: Sunday, February 15, 1998 7:35 PM
> To: Hitoshi Sekine
> Cc: 'PWG-C mailing'; p1284_3 at lexmark.com; p1394 at 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 at microsoft.com>
> ?? : 'Fumio Nagasaka' <fumiona at venus.dti.ne.jp>; 'Stephen
Holmstead'
> <stephen at hpb16977.boi.hp.com>; 'Toru Ueda'
<ueda at slab.tnr.sharp.co.jp>;
> Turner, Randy <rturner at sharplabs.com>
> CC : 'Brian Batchelder' <brianb at vcd.hp.com>; p1394 at pwg.org
> <p1394 at pwg.org>;
> 'PWG-C mailing' <pp1394 at cpdc.canon.co.jp>;
'p1284_3 at lexmark.com'
> <p1284_3 at 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 at venus.dti.ne.jp]
> >> Sent: Saturday, February 14, 1998 9:04 PM
> >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> >> Cc: 'Brian Batchelder'; p1394 at pwg.org; 'PWG-C mailing';
> >> 'p1284_3 at 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 at exc.epson.co.jp
> >>
> >> -----Original Message-----
> >> From: Stephen Holmstead [SMTP:stephen at hpb16977.boi.hp.com]
> >> Sent: Saturday, February 14, 1998 12:59 PM
> >> To: 'Toru Ueda'; Turner, Randy
> >> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394 at 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
> >>
>
>