We did. We said it was required by the spec. Any driver
which does not supply an outstanding TRANSPORT_T2I_DATA command
on an open (T2I) queue is non-compliant.
> 2. Transport requirements
>
> Greg Shue:
> > I suggested that he create a written alternate proposal for the
> > next PWG meeting, so that his concerns get raised.
>
> Yes, I will.
>
> Greg Shue and Fumio Nagasaka:
> fn> gs>
> fn> gs> Defined SBP-2 No | Yes
> fn> gs> command set
> fn>
> fn> This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
> fn> I mean 1284.4 is abstracted from any data link layer and it
> fn> does not have any dependency for data link design. If you
> fn> want to say your commands have some dependency for SBP-2
> fn> in words "defined SBP-2 command set", I feel it is better
> fn> to develop command set which does not have any dependency on
> fn> data link layer. We are defining transport layer.
>
> gs>
> gs> Nope, we are defining a complete stack up through the transport
> gs> layer. This means we must also define the "data link" layer and
> gs> how to glue them together. Without an SBP-2 command set, there
> gs> is no SBP-2 based solution.
>
> When we are defining a data link layer which is applicable
> for other transport protocol, then may be open/close/move
> data I2T or move data T 2I/ are enough functions in this
> layer. However if you say we are defining "a complete stack
> up through the transport layer", then we shall provide
> services to ease a session layer to find or to use facilities
> provided in the 1394 PWG peripherals. So we shall provide
> some higher service capability and functions abstracted
> from SBP-2 transaction.
Or provide it in Config ROM. Nothing says that it must be
done on top of SBP-2.
> A SBP-2/1394 PWG supportive printer provides 1284 PnP ID in a
> configuration ROM. So a higher level protocol driver
> may read textual descriptor from the configuration ROM.
> But this method has a strong dependency for 1394 bus
> system...
So does a 1284 negotiation for Device ID.
So does whatever process is necessary to extract the Device ID
from USB. The "strong dependency" of the method is not
a reasonable argument.
-- Greg Shue Hewlett-Packard Company All-in-One Division gregs@sdd.hp.com ----------------------------------------------------------------