Randy
> -----Original Message-----
> From: Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent: Monday, December 15, 1997 11:04 AM
> To: rturner@sharplabs.com
> Cc: Nagasaka.Fumio@exc.epson.co.jp; p1394@pwg.org;
> 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;
> gregs@sdd.hp.com; rturner@sharplabs.com
> Subject: Re: P1394> RE: TEL-Conference
>
>
> "See my comments below..." :-)
>
> -- 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?
[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 nagasaka.fumio@exc.epson.co.jp
> > >
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs@sdd.hp.com
> ----------------------------------------------------------------