( 3 ) 1284.4 Over Data FIFO Architecture (DFA)
( 0 ) 1284.4 Over SBP-2
( 5 ) Direct Printing Protocol - (current PWG-C proposal 0.71)
(10 ) SBP-2 Native - (current PWG proposal 0.1c)
( 8 ) Other - IP1394
( 4 ) Other - AVC
( 6 ) Other - SBP-2 mirroring Thin Protocol
2. Please provide background comments on your ranking.
For Unadiminstered PC connect:
Why do you prefer to use the given solution?
Support by multiple major desktop OS vendors
Lower CPU overhead on PC
Can be used for other devices
Support for async and isoch
Errors are testable/verifiable
Consistant with the CSR & Unit Directory Architecture
HW vendors providing HW assists already
Does not require support for large MTU sizes
Flow control is implicit, not explicit as with CBT
Why should others consider the given solution?
See above comments
Does the the given solution meet the existing requirements?
Yes
What issues are you aware of (if any) with the given solution?
Obtaining access to a service instance is potentially inefficient.
Unexpect data transfers to PC are not optimally supported.
How to identify which Application command set is associated
with a service.
What is your opinion on the best way to move the discussion forward?
Get concensus on how may protocols _will_ exist (see below).
Reaffirm the solution space being addressed.
Compare with other proposals.
Other comments?
Work is under way to provide support within SBP-2 for
transient link interruption support. No negative feedback
has been shared on the T10 reflector. The proposal will be
reviewed on March 10, 1998. If the extension is addopted,
then the complexity of the SBP-2 Native Profile proposed drops
by half.
3. Opinions on multiple printing protocols;
(10 ) Other
IP happens - This provides a backwards compatible solution space
for enterprise environments. This is a needed solution.
It removes a barrier to adopting the technology.
(This seems like the "luxury/full-size car" of protocols)
AVC is (?) - This provides a solution for the current AV 1394
products which customers have already bought. There
is not much that we can do about it, though it seems
to potentially waste a large amount of (shared) 1394
bus bandwidth. I understand why it was based on Isoch,
bu I would have preferred an Async solution.
(This seems like the "alternate fuel cars" of protocols)
Light - There is now a _real_ application space associated with
Peer-to- printing which does not fit the traditional client/server
peer will model. The current protocols are inappropriate or too
be heavy for this application space. Because this is real,
this will happen. Because it is a different paradigm,
this needs to happen.
The only question is what will it look like. We
need exactly one well-defined, thoroughly
testable, certafiable protocol in order to help
deliver interoperability of embedded devices.
(This seems like the Sport/Utility Vehicles of protocols)
Proprietary - These will exist. These must be allowed. We can't
cover every need, so a safety net for custom solutions
must be acknowledged. The best that we can do is try
to educate the developers on any coexistance issues
and best practices that have been found during
our standardization efforts.
(This seems like the "custom" cars of protocols)
Unadmin. - This is really the "optional" area. The other protocols
PC connect span the solution space, though none are optimal. I
think this will happen because:
- MS and Apple prefer it for printer connectivity
- Printer vendors want it
- If it's not standardized, it will be there as a
proprietary solutions anyway
(This seems like the small/midsize cars of protocols)
So,
I think all five protocol categories except the Unadministered
PC Connect _must_ exist because they provide non-overlapping
solutions to real problems.
I think the Unadministered PC Connect (i.e. "Parallel Port
replacement) should exist for technology adoption and business
opportunity reasons even more so than technical ones. "The
small/midsize car market is real."
I think we should try hard to avoid having more than one
protocol per category. For various reasons, I would like to
share as many mechanisms (e.g. access control) as possible
between the protocols.
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------