Subject: P1394> Re: Native SBP-2 Printer Profile?

From: "Eric Anderson" <[email-masked]>
Date: 20 Feb 98 11:38:15 -0800

I don't believe the entire printer model has to be standardized,
we just need a way to communicate basic operational steps, such
as start a job, report status, report errors, etc.  Within such
a framework, and number of formats, protocols, etc, are possible.

If after running out of paper you'd like to load more and continue,
you can just requeue the same ORB and let the printer pick up from
where it left off.  (I would design the native printer profile so
that the printer can remember where it was in that ORB, and not
execute the same parts twice.)  My statement shouldn't be read to
imply that any error causes a total shutdown - just that the
printer will wait for further instructions.

--------------------------------------
Eric Anderson            [email-masked]
Apple Computer, Inc.      408-974-8187
--------------------------------------

> Interresting thoughts, though the PWG is not trying to create
> a truly native SBP-2 printer profile.  As I think about it, I
> don't know of _anyone_ that is.
> 
> Your thoughts imply that:
> 
>   - a truly native SBP-2 printer profile has a standard "printer"
>     device model with standardized status info.
> 
>   - the printer is being driven by an intelligent agent which is
>     aware of command boundaries.  So it's either driven directly
>     by the printer driver, or by a command-set-intelligent spooler.
> 
> 
> By the way, I don't want my printer to throw away the rest of
> the data when it runs out of paper.  I want it to tell me it's
> out of paper, wait for me to put paper in, and then continue
> printing.  :-)
> 
> > As part of a truly native SBP-2 printer profile, I would expect
> > to include a sequence number or something in the ORB command,
> > so that a target can be sure not to execute the same command
> > twice.  I would also allow a target to abort at any point it
> > likes and communicate this to the initiator.  For example, 
> > "I ran out of paper between commands 4 and 5 in ORB 1129
> > and I flushed further execution.  Tell me what to do now.".
> > 
> > --------------------------------------
> > Eric Anderson            [email-masked]
> > Apple Computer, Inc.      408-974-8187
> > --------------------------------------
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			[email-masked]
> ----------------------------------------------------------------

---

From: Greg Shue <[email-masked]>
Date: Fri, 20 Feb 1998 12:15:40 -0800 (PST)

> a framework, and number of formats, protocols, etc, are possible.

Agreed.  The PWG has already agreed (?) that a print job is
a separate data path than device status.  No one has raised
the topic of reporting formatting errors.  I don't know if
it's a general issue or not.

> printer will wait for further instructions.

I was trying to avoid the printer having to verify that the
same ORB was requeued and remembering the offset into it. I've
always had the impression that it would be more problematic
than breaking the data up into transport-level blocks.  Perhaps
you can convince me otherwise.  Would you try?

---

From: Akihiro Shimura <[email-masked]>
Date: Fri, 27 Feb 1998 21:05:48 +0900 (JST)

Hi,

I have a question regarding the necessity of buffer identifier (or
sequence number) in the ORB command.

In the Annex E. of SBP-2 Rev.3a, the following is described.

  E.4 Status FIFO write request
   When the target detects a missing acknowledgement after a write to
   an initiator's status FIFO, it should take no error recovery
   actions. Any target resources allocated to the ORB should be
   released by the target. The initiator is expected to discover the
   error by means of a higher-level mechanism, such as a command
   time-out and to initiate appropriate error recovery. The nature of
   the error recovery undertaken by the initiator likely depends
   whether or not the target processes ORB's and returns their status
   in order, but in any event is beyond the scope of this description.

If this happened and followed by bus reset, it seems initiator loses
synchronization with target. I suppose the sequence number or
something may be useful in this situation to avoid duplicated ORB.

Am I missing something?

Akihiro Shimura

On Fri, 20 Feb 1998 12:15:40 -0800 (PST)

--
 Akihiro Shimura ([email-masked])
 Office Imaging Products Development Center 3
 CANON INC.

---

From: Greg Shue <[email-masked]>
Date: Fri, 27 Feb 1998 12:12:29 -0800 (PST)

> something may be useful in this situation to avoid duplicated ORB.

I know you caught something which I have missed.  I wasn't fully
aware of this clause, and it certainly needs to be addressed to
deliver reliability.

The buffer identifier (or sequence number) helps filter out
redundant buffers, which solves part of the problem.  The more
signficant issue is:

  How does a PWG Imaging Communications Profile initiator
  _detect_ that it should try to recover from a lost Status_FIFO
  write acknowledge?

    The Status_FIFO is written to:
      A) at the end of every Management Agent request
	  (so this should be defined by SBP-2 for Management
	   Agent commands.  I don't recall that it is.)

      B) at the end of every request on the task list
	  (within the scope of the device profile)

      C) as the mechanism for communicating Unsolicited Status

I'll be thinking about these for a while ...