1) I agree that this option is dead.
2) I think option 2 could work, but there is some political resistance
from the camera guys to adding 1284.4. It's heavier than Thin Protocol
(Thin doesn't have multiple channels). There would have to be a
definition of how 1284.4 sits on top of 1394, but I don't think that
there needs to be another layer between 1284.4 and 1394.
3) I really don't like SBP-2. SBP-2 is an EXCELLENT model for existing
storage devices. It is NOT a good model for peer to peer devices.
Sure, the initiator/target model can be modified to have a target notify
the initiator that data is available, but it is kludgy. Aborting the
task queue is an exceptable solution if your model is primarily single
direction data flow. But in a peer to peer environment, the data
direction is going to switch a bunch. That is just not an exceptable
design. Bottom line, you can make initiator/target model do peer to
peer, but it won't do it well.
4) DPP is not a transport layer. The Thin Protocol (defined in the DPP
spec) that sits BELOW DPP is a transport layer. I like Thin Protocol.
It's very lightweight. I don't think anybody could complain about
adding the code to implement Thin Protocol. It doesn't provide multiple
channels, but it does do segmentation/reassembly. It provides a very
generic and simple "stream" transport.
5) I would be happy with IP/1394. It would allow us to have UDP and
TCP transport layers that are already familiar to many. Unfortunately,
I think this option is viewed by many to be "heavy", but it doesn't have
to be. I don't care about DHCP, DNS, and other administrative
protocols. I just want the transport layer (UDP/TCP). The real problem
here is that it's going to take a long time until committees decide what
IP/1394 is. If we are in a rush, this option isn't it.
So, in summary, option 4 looks like the leader in my book. Options 2
and 5 also have merit. That's my opinion. Anyone else?
Stephen Holmstead
> -----Original Message-----
> From: ALAN_BERKEMA@hp-roseville-om2.om.hp.com
> [SMTP:ALAN_BERKEMA@hp-roseville-om2.om.hp.com]
> Sent: Tuesday, February 17, 1998 3:15 PM
> To: p1394@pwg.org; pp1394@cpdc.canon.co.jp
> Subject: P1394> Print Protocols
>
>
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> 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?
>
>
> Alan