-- Greg S.
> See my comments below...
>
> Randy
>
> > -----Original Message-----
> > From: Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
> > Sent: Monday, December 15, 1997 3:13 AM
> > To: 'p1394@pwg.org'
> > Cc: 'brianb@vcd.hp.com'; 'alan_berkema@hp.com';
> > 'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com';
> > 'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'; 'Randy Turner'
> > Subject: P1394> RE: TEL-Conference
> >
> > I'm sorry for inconvenience for multiple copy of this mail through the
> >
> > mailing list.
> >
> > I have some comments for PWG-printing profile.
> >
> > 1. Login/Logout
> >
> > Some consumer operating systems invoke "login" at boot time, and never
> >
> > logout
> > until shut down. This scheme was designed intended to support SBP-2
> > HDD as
> > a boot device. However this scheme is not smart to support PWG
> > printer.
> [Turner, Randy] I agree, automatic login at boot time should
> not be
> required to support printing. But plug'n play may require this
> feature,
> and its not clear whether or not this causes a problem yet for
> 1284.4
> printing.
A similar issue may still exist:
Does PnP of 1284.4 devices automatically open a channel at
boot time to all the services found?
No matter what, we need to define the policy and behavior of the
initiator when more initiators are trying to interact with our device
than the our device has resources to support.
Exactly which initiators don't get access to the device?
Does this policy give the customer a predictable mapping?
> > May be, "login" and "logout" shall be associated with DL_register and
> > DL_unrgister.
> > Thus I feel PWG-profile shall specify the timing for login/logout.
> > These facilities
> > ought to be implemented in Data Link stuff
> > (DL_register/DL_unregister).
> [Turner, Randy] I like this idea. The DL_register and
> DL_unregister
> entry points for the 1394-based DL would translate these calls
> into login and logout calls. It seems to make sense for how
> these
> entry points were originally designed to work.
So how does this fit in with "transient cable disruptions"
which last more than 1 second? What takes care of the disruptions?
>
> > 2. Login waiting time
> >
> > IEEE 1394 provides network-like platform for PCs.
> >
> > - PC A is printing a document using Printer X.
> > - PC B is waiting to start printing while 10 seconds.
> > - PC C is waiting to start printing while 10 minutes.
> >
> > Then PC C shall be allowed to start printing session earlier than PC
> > B.
> > I felt current PWG protocol stack does not provide any answer to solve
> >
> > this issue.
> > Because PC B or PC C may invoke login while PC A is printing. When PC
> > A
> > is printing, the data channel shall be busy, so IEEE 1284.4 transport
> > replies busy
> > status if PC B or PC C try to open this channel. But after PC A closed
> >
> > this
> > data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel
> > earlier than
> > other PC to open this data channel.
> [Turner, Randy] The description of this "problem" is really an
> implementation issue. This scenario says that the 1284.4
> printer would return "busy" if an OpenChannel was attempted
> while the printer was printing over a previously opened
> connection. However, the printer may elect to accept an
> OpenChannel from as many potential clients as possible,
> and only accept data from the first connection. The other
> open channels would be processed in some order, as
> each printing session completes. The other connections would
> be flow controlled until the printer is ready to accept
> data on each channel.
>
> Basically, the policy that is used for printing arbitration
> is not defined by 1284.4. It is defined by the application
> using the 1284.4 transport. Therefore, I don't think the
> proposal for an OpenChannel_solicitation is necessary.
> If this type of functionality is needed, it would be an
> application function, not a transport function.
>
> Randy
Randy's reasoning sounds good. The more I think about it, though,
the more I think the device sharing solution goes beyond our control.
PC A may have 10 more jobs in it's spooler that are 3 hours old, and
PC C's job may be only 10 minutes old. We don't have enough knowledge
to make a completely fair choice from the users' perspective.
The application can determine policy for arbitrating between all the
requests it can maintain at once, but we have to define (or acknowledge)
what happens when it the application refuses additional requests.
> > To solve this problem, we need to introduce "OpenChannel_solicitation"
> >
> > which is
> > an unsolicited status to inform PC C that PC A closed printing session
> >
> > and now you
> > may call OpenChannel.
> >
> > Alan's document is describing two "status_code" shown below,...
> > 0x01 data transfer complete
> > 0x02 target to initiator transfer request
> >
> > I would like to suggest third "status_code",
> > 0x03 target allows initiator to open 1284.4 data channel
> >
> > PC C may login at any time, however while PC A is printing PC C is
> > not
> > allowed to use same data channel with PC A. The target device allows
> > the initiator which invokes "login" earlier than other initiator, to
> > open data
> > channel, after previous data session had been closed.
> >
> > And may be we need to provide other message to say,
> > __ttt__ initiator allows target to open channel
> > As you know this function shall be provided utilizing ORB, because it
> > might
> > be a solicitation from an initiator to the specified target. Then can
> > PWG profile
> > use normal command block ORB?
> >
> > Someone, could you kindly suggest tel-conference agenda if you have
> > spare
> > time in Monday morning? ( I will go to sleep, as tel-conference starts
> >
> > from
> > Tuesday morning at 6:00 AM in Japan)
> >
> > Thank you, best regard.
> > --------------------------------------------
> > -------------------------------
> > 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
> >
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------