P1394 Mail Archive: P1394> PWG Profile Scope (was 1394 Timers?)

P1394 Mail Archive: P1394> PWG Profile Scope (was 1394 Timers?)

P1394> PWG Profile Scope (was 1394 Timers?)

Greg Shue (gregs@sdd.hp.com)
Tue, 8 Sep 1998 09:33:49 -0700 (PDT)

Fumio Nagasaka:
> Thus we at 1394 PWG shall describe a method to force an
> initiator to provides ORBs without utilizing unsolicited
> status from the target. Because some operating system does
> not support this functionality.

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