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.
Actually on a consumer PC operating system platform designed in north
California,
our driver may invoke "login" at any time.
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).
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.
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
-----Original Message-----
From: Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
Sent: Saturday, December 13, 1997 10:46 AM
To: 'Randy Turner'
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'
Subject: RE: TEL-Conference
Hi Randy,
We ware discussing some points through e-mail. I was so sorry, I
forgot who
was the organizer for this telephone conference. Thus I sent e-mail to
several
persons who I expect to be a correct person.
At 01:53 AM 12/13/97 +0900, Fumio Nagasaka wrote:
>Hi there,
>
>May I confirm schedule and phone number for the tel-conference
>on December 15 at 4:00 PM?
>Do I need to make a phone-call to your phone number? Or can I
>wait your phone call in my office?
--------------------------------------------
-------------------------------
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: Saturday, December 13, 1997 9:08 AM
To: Fumio Nagasaka
Cc: gregs@sdd.hp.com; 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
Subject: Re: TEL-Conference
> Greg writes;
> >Personally, I prefer putting the 1284.4 command packet within the
> >data block of the ORB. This means that the CDB needs to contain
> >the commands that:
> > SENDMSG (?) - transfer all data to the target
> > RECEIVEMSG (?) - receive <= blocksize bytes from the target (msg
> boundary)
> > RECEIVEBLOCK (?) - receive exactly blocksize bytes from the
target
>
> The direction bit in a "Normal command block ORB" shall specify
read/write
> direction from the initiator. These commands seem to have some
redundancy.
> Greg do you have any special reason to have these commands ?
I have no special reason other than to distinguish the RECEIVEMSG
request from the RECEIVEBLOCK request. Even that may not matter.
Looking at the Simple Hrd Disk Drive Profile, they support the
following (SCSI) commands:
MODE_SELECT (10)
MODE_SENSE (10)
READ (10)
START/STOP UNIT
SYNCHONIZE CACHE
TEST UNIT READY
WRITE (10)
WRITE AND VERIFY (10)
WRITE BUFFER, Mode (101b) (Download Microcode and Save)
As for a general protocol, I can see value in specifying Read
and Write commands simply to reserve space for other commands
we might want for testability or general functionality. Or, if
we need to specify a command which has both a data payload for
each direction. (Yes, I know this is the infamous bi-di ORB
which was rejected as a standard part of SBP-2. I have no idea
how or why we would use something like that, but I would not
want to preclude it's availability).
> I suppose we can discuss through the e-mail. Thus we don't need to
have
> telephone conference. Alan, could you please inform us your plan?
Now that there is some discussion going on, I would prefer to keep it
in e-mail.
> -------------------------------
> Fumio Nagasaka
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------