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 ----------------------------------------------------------------