P1394 Mail Archive: Re: P1394> Print Protocols

P1394 Mail Archive: Re: P1394> Print Protocols

Re: P1394> Print Protocols

Brian Batchelder (brianb@vcd.hp.com)
Tue, 17 Feb 1998 16:02:23 -0800

At 02:15 PM 2/17/98 -0800, ALAN_BERKEMA@HP-Roseville-om2.om.hp.com wrote:
>This was "RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes"
>however I figured it was time for a new name.
> Ozay Oktay wrote:
> I have been quietly monitoring this discussion on the reflector. So
> far this is the best analysis I have read.
> I agree with Brian almost entirely.. When preparing a standard we must
> look into the future. We could be accommodating but we should never be
> constricting for the sake of backward compatibility.
> Best Regards
> Ozay Oktay
> Canon Information Systems
>I will second that, good job Brian.

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?

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 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