I brought up this idea at 1394 PWG on September 15, 1997.
Please show the meeting minutes posted below. Was it many,
many months ago?
III.B.2 Fumio Nagasaka-Epson
SBP2 Printing Model
Minimal requirements for PC Printing protocol
Multiple Logical Channels
Multiple Hosts Connectivity
Multiple Targets Connectibility
Reconnection after bus reset
Multiplexing to support multiple clients for the transport.
Implementation of multiple logical channels through SBP2
How many logins does one printing session require
*1-Build MLC internally within one login*
2-Requires multiple login as same number of logical
Unfortunately we spent many months getting few results.
Greg Shue wrote:
* If we want to have a standard FAX driver stack, then I would
* encourage us to start an e-mail discussion about how a standard
* FAX device should be modeled.
I just said for example any unit may have multiple logical channels.
Not only printer but also scanner or FAX could have MLC.
I have no urge to discuss FAX driver stack in this e-mail.
Greg Shue wrote: (reformatted)
> $B!D(J.. That provision(J
> already exists by using the current proposal in packet mode and
> making the supported packet size (per direction) be able to hold
> the largest packet transferred in that direction. Since the
> current proposal supports packets of 65535+6 bytes, nothing needs
> to be changed. The nature of CBT will prevent the fetch agent
> >from blocking while waiting for a data transfer. No data
> transfer commands will be sent which could not be immediately
> processed. No out-of-order processing is required.
Agreed. I think we can eliminate out-of-order processing model.
My motion is to vote elimination of out-of-order processing model
at Portland meeting.
To have productive result we must move forward. We shall start
from Greg and Alan$B!G(Js proposal.(J
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to Nagasaka.Fumio@exc.epson.co.jp
From: Greg Shue [SMTP:firstname.lastname@example.org]
Sent: Thursday, March 12, 1998 2:08 AM
To: Nagasaka Fumio
Cc: email@example.com; firstname.lastname@example.org
Subject: Re: P1394> unordered execution
Your concern comes because you have a new requirement under
multiple channels being _associated_ with a
single session (login to a LUN).
This should have been brought up many, many months ago.
The current requirements are for multiple _independent_
No discussion has occurred about what the standard FAX model
should look like. Apparently your model is different from others as no
one else has raised this requirement.
If we want to have a standard FAX driver stack, then I would
encourage us to start an e-mail discussion about how a standard FAX
device should be modeled.
I$B!G(Jm not suprised that a consumer OS provides one login per LUN.(J
Nothing has been clearly stated about how SBP-2 LUNs should be treated.
The Microsoft SBP-2 implementation has it$B!G(Js own behaviors which must be(J
addressed. I don$B!G(Jt have any issues with saying that $B!H(Jthis is the(J
standard way of supporting XXX device.$B!I(J
Nothing prevents providing a 1284.4 service on top of the
current proposal. This may be the direction you choose to go if your
FAX service is modeled as having more than a unidirectional SEND channel
and a unidirectional RECEIVE channel, and you don$B!G(Jt want to model each(J
data source/data sink as a different service.
I have a couple of issues with supporting $B!H(JMLC$B!I(J over a single(J
list, so I$B!G(Jll assume you meant $B!H(JCBT$B!I(J (1284.4). That(J
already exists by using the current proposal in packet mode and
making the supported packet size (per direction) be able to hold
the largest packet transferred in that direction. Since the
current proposal supports packets of 65535+6 bytes, nothing
to be changed. The nature of CBT will prevent the fetch agent
>from blocking while waiting for a data transfer. No
transfer commands will be sent which could not be immediatly
processed. No out-of-order processing is required.
> On Sun, 8 Mar 1998 22:24:59 -0800
> $B!H(JTurner, Randy$B!I(J <email@example.com> wrote:(J
> > <RT>We should never have a single ORB list
processing multiple logical
> > channels. Each ORB <RT>list handles a single
logical channel, at least
> > according to the current profile document
<RT>decisions we have made.
> We need to invoke some login(s) to make some fetch
> I don$B!G(Jt like it, because,...(J
> 1) Multiple logical channel shell be involved with a
> For example, FAX LUN may have several logical
> According to the current profile document, we are
> required to invoke login(s) to a LUN or to some
> 2) However Sekine-san told us, a consumer OS invokes
> login to a LUN.
> 3) So we need to have a facility to provide MLC in a
> ORB List.
> The current profile document is good and well
> so we need to revise some points to make it is
> existing Operating System.
> Fumio Nagasaka
> EPSON Software Development Laboratory Inc.,
> TEL: +81 268 25-4111 // FAX: +81 268 25-4627
> HomePage = http://www.venus.dti.ne.jp/~fumiona/
Office Products Division firstname.lastname@example.org