OK, stop it. My head is getting too big. ;-)
>So, from attempting to follow the discussion it seems to me that we have.
>
>1) 1284.4 over SBP-2 over 1394.
>
>Rough consensus that this is not a great idea.
>
>2) 1284.4 over 1394.
>
>I don't think this works by itself? We still need a layer that takes the
>1284.4 packet and puts it into a 1394 packet with a 1394 address. As Brian
>and others have mentioned DFA does this, however, DFA does not handle out
>of order, lost or duplicate packets.
I assume that we could take DFA and add the functionality required to
handle out-of-order, lost and duplicate packets. If we did that, we would
need to compare our solution to SBP-2 to make sure that we didn't end up
re-inventing it. I've seen that happen all too often...
>3) SBP-2 over 1394.
>
>Has merit. Good native 1394 solution that takes advantage of 1394's memory
>address capabilities and works well with descriptor based DMA.
>
>If PC nodes only want to be Initiators we don't have a symmetric solution.
>I think we can make it work, though, I am concerned that non PC peers that
>implement both Target/Initiator functions would need to communicate with
>each other in a different way than when they communicate with a PC?
I don't know if we should assume that PC-nodes will only be initiators,
even though George Chrysanthakopoulos at Microsoft indicated that PC
targets would not be supported. I hope that we can change his mind by
showing him why PC targets are important. BTW, I agree with him that
PC-connect devices could be implemented as targets, but, again, I would
prefer not to limit our future solutions in that way.
>4) DPP over 1394.
>
>Sounds good. I have not seen enough of the detailed mechanism to determine
>if it delivers (I need to learn more about DPP). Did receive some comments
>at the TA about totally inventing a new mechanism instead of reusing
>existing protocols, though it could be the right answer.
I agree with the concerns of the TA. Any protocols we specify MUST provide
solutions in a significantly better way than do the other available
protocols. If they do not, companies will not implement our protocols, and
they will end up being a waste of time. In addition, too many protocols
can confuse the industry and our customers, diluting the effect of the
primary ones.
>5) TCP/IP over 1394.
>
>I think this is a given. (IP happens). This could give us printing similar
>to the way it works today, as well as all the new internet possibilities.
>Address administration and configuration, (DNS and DHCP and others as
>Michael points out), make a full implementation larger than some devices
>might like. Not sure of the use model?
>
>Conclusions?
IMHO, there will be at least two printing protocols for 1394, TCP/IP and
something else. If TCP/IP and that something else can't solve the needs of
low-end image printing, parallel-port replacement printing and "network"
printing, then we will need three printing protocols. No matter what we
end up choosing, my personal goal is that, a few years from now, our
protocols are in widespread use, providing strong value to our customers.
(Hey, maybe I have a career in Marketing ahead!) ;-)
Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder | Hewlett-Packard | mailto:brianb@vcd.hp.com
Connectivity Futurist | 1115 SE 164th Ave. | Phone: (360) 212-4107
DeskJet Printers | Vancouver, WA 98684 | Fax: (360) 212-4227