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?
<<<
ftp://ftp.pwg.org/pub/pwg/p1394/mtg091597/9709_min.pdf
III.B.2 Fumio Nagasaka-Epson
SBP2 Printing Model
Minimal requirements for PC Printing protocol
Multiple Logical Channels
Flow Control
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
channel
3-Prioritize logins
>>>
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)
> ….. That provision
> 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’s proposal.
-------------------------------------------------------------
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: Greg Shue [SMTP:gregs@sdd.hp.com]
Sent: Thursday, March 12, 1998 2:08 AM
To: Nagasaka Fumio
Cc: p1394@pwg.org; pp1394@cpdc.canon.co.jp
Subject: Re: P1394> unordered execution
[Shue, Greg]
Your concern comes because you have a new requirement under
issue 1:
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_
channels.
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’m not suprised that a consumer OS provides one login per LUN.
Nothing has been clearly stated about how SBP-2 LUNs should be treated.
The Microsoft SBP-2 implementation has it’s own behaviors which must be
addressed. I don’t have any issues with saying that “this is the
standard way of supporting XXX device.”
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’t want to model each
data source/data sink as a different service.
I have a couple of issues with supporting “MLC” over a single
ORB
list, so I’ll assume you meant “CBT” (1284.4). That
provision
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 immediatly
processed. No out-of-order processing is required.
> On Sun, 8 Mar 1998 22:24:59 -0800
> “Turner, Randy” <rturner@sharplabs.com> wrote:
>
> > <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
agents.
> I don’t like it, because,...
>
> 1) Multiple logical channel shell be involved with a
LUN.
> For example, FAX LUN may have several logical
channels.
> According to the current profile document, we are
> required to invoke login(s) to a LUN or to some
LUNs.
>
> 2) However Sekine-san told us, a consumer OS invokes
one
> login to a LUN.
>
> 3) So we need to have a facility to provide MLC in a
single
> ORB List.
>
> The current profile document is good and well
designed. Even
> so we need to revise some points to make it is
executable on
> 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/
>
>
--
Greg Shue
Hewlett-Packard Company
Office Products Division gregs@sdd.hp.com
----------------------------------------------------------------