P1394 Mail Archive: RE: P1394> RE: TEL-Conference

P1394 Mail Archive: RE: P1394> RE: TEL-Conference

RE: P1394> RE: TEL-Conference

Fumio Nagasaka (fumiona@venus.dtinet.or.jp)
Tue, 16 Dec 1997 05:55:48 +0900

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

[Fumio Nagasaka] OS may read Configuration ROM to perform Plug & Play
steps. OS must enumerate any PC peripheral device, even if it speaks AV/C,
IP/1394 or IP/1394. Thus PnP shall be independent from transport layer.

--------------------------------------------
-------------------------------
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: Turner, Randy [SMTP:rturner@sharplabs.com]
Sent: Monday, December 15, 1997 11:28 PM
To: 'Nagasaka Fumio'; '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: RE: P1394> RE: TEL-Conference

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.

> 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).
[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.

> 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

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