Subject: P1394> RE: TEL-Conference

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

I'm sorry about the inconvenient teleconference time
for Japan. The call was setup by another division
because I wanted folks to be able to call in
toll free. I will try and change it to 4 PM PST as
requested by our Japan partcipants. If I am 
successful at changing the time, I will post the
list. Until I can confirm the change, the telecon
time will be 1 PM PST, with the details I sent
out earlier.

Randy

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 15 Dec 1997 11:33:25 -0800

See my comments to your comments....;)

Randy

> -----Original Message-----
> From:	Greg Shue [SMTP:[email-masked]]
> Sent:	Monday, December 15, 1997 11:04 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject:	Re: P1394> RE: TEL-Conference
> 
> 
> "See my comments below..."  :-)
> 
> -- Greg S.
> 
> > 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. 
> 
> 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?
	[Turner, Randy]  
	[Turner, Randy]   
	In either case, I think this is an application issue. I do agree

	however, that performing PnP of 1284.4 devices would be
	a bad implementation for potential clients, but it would not
	impact a server's ability to handle multiple inbound
	connections, at least as far as the 1284.4 layer is concerned.

> > > 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?
	[Turner, Randy]  

	Any link-specific error conditions should be transmitted to
	link-layer clients through the DL_INDICATION or DL_NOTIFY
	type of entry point. It is up to the link-specific code to
	determine whether or not a particular link-layer event should
	cause any or all connections over a particular link to be
	closed.

> > 
> > > 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.
	[Turner, Randy]  

	If we have to recognize application policy, then this would not
	be a normative part of a potential standard; rather, it would be
	included as a part of some informational appendix to a 
	document.

	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]
> > > 
> -- 
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			[email-masked]
> ----------------------------------------------------------------

---

From: Fumio Nagasaka <[email-masked]>
Date: 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.

-----Original Message-----
From:	Turner, Randy [SMTP:[email-masked]]
Sent:	Monday, December 15, 1997 11:28 PM
To:	'Nagasaka Fumio'; [email-masked]'
Cc:	[email-masked]'; [email-masked]'; [email-masked]'; 
[email-masked]'; [email-masked]'; 'Greg 
Shue'; 'Randy Turner'
Subject:	RE: P1394> RE: TEL-Conference

See my comments below...

Randy

> I'm sorry for inconvenience for multiple copy of this mail through the
>
> mailing list.
>
> 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

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

> 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

	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.
>
> 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
> 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
> 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
> From:	Fumio Nagasaka [SMTP:[email-masked]]
> Sent:	Saturday, December 13, 1997 10:46 AM
> To:	'Randy Turner'
> [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?
> 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.
>