Subject: Re: P1394> Print Protocols

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

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 wrote:
> This is true if the tasks being processed by the target are
> idempotent.  (In other words, that they may be executed one or
> more times and end up with exactly the same result.)  This
> feature is needed to support the following situation:
> 
>   - a task to be partially processed
>   - a Bus Reset to occur (which implicitly aborts the task)
>   - the task requeued on the list
>   - the task completely restarted
>   
> I think this is an inheirent attribute of mass storage commands.
> Unfortunately, printers are not.
> 
> Sending a set of commands which are larger than the printer can
> buffer forces the printer to process some commands before they
> are all received.  If a Bus Reset occurs, then either the printer
> must validate that the same ORB was requeued and try to resume
> from the last valid offset fetched, OR the protocol can guarantee
> that the ORB's data block has been completely transferred before
> the data is processed.  The first case is difficult at best, the
> second is easy and provides idempotency at the cost of
> negotiating the maximum sizes of the data blocks referenced by
> the ORBs.
> 
> So, it's easier for the initiator to be aware of the transport
> packet sizes supportable by the target than it is to work around
> the Bus Reset problem by another mechanism.  If you have a better
> suggestion, I'll certainly consider it.
> 
> "Need" is relative to the context.  In this thread, we're talking
> about using SBP-2 for printing services.

---

From: Greg Shue <[email-masked]>
Date: Fri, 20 Feb 1998 10:07:02 -0800 (PST)

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

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------

---

From: Jack Hollins x2309 <[email-masked]>
Date: Fri, 20 Feb 1998 15:56:51 -0800

See embedded comments

> and I flushed further execution.  Tell me what to do now.".

Since I think we are talking about SBP-2, I will expand on the above
statement tohave meant the following.  'I ran out of paper after
completing command 4 in ORB 1129
and I flushed further execution.  Tell me what to do now.'

I wanted to clarify that your original statement did not imply that
there could be
multiple commands per ORB.  This in not allowed in SBP-2 (section
5.1.2).

In fact I believe the appropriate sequence would be the return of good
completion
status for ORB 1129, detection of the out of paper condition,
unsolicited status
transfer from target to initiator indicating the out of paper condition.

The printer fetches the ORBs from the initiator.  The printer is aware
of its
buffer limitations and I assume (maybe incorrectly) that it should take
its buffer
limitations in to account when determining when to fetch the next ORB.

If a bus reset occurs, the printer will clear any pending tasks and
transition to the
reset state.  The initiator knows exactly which ORBs in the task set
were executed
based on the return of completion status.  Therefore it should be clear
to the
initiator what ORB address to use in a write to the ORB fetch pointer
CSR to continue
execution of the task set after the fetch agent is initialized.