Subject: RE: P1394> RE: TEL-Conference

From: "Turner, Randy" <[email-masked]>
Date: Mon, 15 Dec 1997 06:28:03 -0800

See my comments below...

Randy

> -----Original Message-----
> From:	Nagasaka Fumio [SMTP:[email-masked]]
> Sent:	Monday, December 15, 1997 3:13 AM
> To:	[email-masked]'
> Cc:	[email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; '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 [email-masked]
> 
> -----Original Message-----
> From:	Fumio Nagasaka [SMTP:[email-masked]]
> Sent:	Saturday, December 13, 1997 10:46 AM
> To:	'Randy Turner'
> Cc:	[email-masked]'; [email-masked]'; 
> [email-masked]'; [email-masked]'; 
> [email-masked]'; '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 [email-masked]
> 
> -----Original Message-----
> From:	Greg Shue [SMTP:[email-masked]]
> Sent:	Saturday, December 13, 1997 9:08 AM
> To:	Fumio Nagasaka
> Cc:	[email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> 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			[email-masked]
> ----------------------------------------------------------------

---

From: Greg Shue <[email-masked]>
Date: Mon, 15 Dec 1997 11:04:25 -0800 (PST)

"See my comments below..."  :-)

-- Greg S.

> 	and its not clear whether or not this causes a problem yet for

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?

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

> 	application function, not a transport function.

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.

---

From: Brian Batchelder <[email-masked]>
Date: Mon, 15 Dec 1997 11:56:24 -0800

More comments...

Brian

>  boot time to all the services found?

[Brian] We don't want PnP to "bring-up" the I/O stack, except where
required to enumerate the devices, functions, services and the I/O stack
itself.  Once enumeration is complete, all I/O connections should be
closed.  Later, when the first application requests access to a service,
the appropriate I/O stack is loaded and a connection is established to the
device.  When all applications requesting access to services have
"completed" their work (whatever that means), the connections are closed.
We cannot allow PCs to dominate access to devices in the interconnected
world of 1394.

>  Does this policy give the customer a predictable mapping?

[Brian]The simplest way to implement this is as a FIFO.  Whoever asks first
gets access.  Note that the device MUST be released when the initiator has
finished using it.

>which last more than 1 second?  What takes care of the disruptions?

[Brian} The data link should hide all disruptions that we wish to make
transparent.  The transport should be notified when the link is disrupted
for a longer time.

>what happens when it the application refuses additional requests.

[Brian] I also like Randy's idea.  Our transport needs to be symmetric,
therefore it must have facilities that allow the server to switch between
clients.  How it decides to switch between them may be an implementation
issue or we may have to standardize some of it.  Isn't there a model in the
network world for this?  Shouldn't we look at that model?

Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:[email-masked]  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227