P1394 Mail Archive: P1394> Re: [PP1394:00208] Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)

P1394 Mail Archive: P1394> Re: [PP1394:00208] Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)

P1394> Re: [PP1394:00208] Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)

Atsushi_Nakamura (atsnaka@bsd.canon.co.jp)
Tue, 24 Feb 1998 10:06:37 +0900

At 02:36 98/02/24 +0900, Greg Shue wrote:


> OK, here's my preference...


> "I am going to love using SBP-2 for peer-to-peer!


> (And, with a different SBP-2 command set, I'll love using it

> in a different way for PC printing!)"


Has this been discussed with the "input" or "device-source" people ?

Peer to Peer is different from PC printing because we have to take

requirements and restrictions of the input devices in to consideration,

whereas the PC has pratically no restrictions (PC can do anything.)

No matter how much we, the printer guys may like SBP-2, peer to peer

can only be achieved if the image source support the (appropriate

functions of) same protocol.

Now, my question is :

Q)Has anyone actually discussed with the input people about implementing

BOTH initiator and target SBP-2 in input devices for peer to peer ?

Q)The scanner may prefer a SCSI-like solution , especially because of it's

origin as a PC peripheral, but how about digital cameras?,DV camcorders?

Toru Ueda wrote:

> We are developing DPP and THIN protocol. The biggest priority for THIN

> protocol is the size and simplicity. I cannot explain the reason we

> need two logins for simple print task to our product engineers. Also I

> cannot explain the reason we need 20 or 30KB for print protocol, while

> the file transfer protocol using IR(Infra-Red) communication (called Ir

> TranP) needs only several Kilo bytes.

People like Ueda-san and others of the PWG-C HAS been discussing

these issues with input people from not just the office products area,

but the consumer market people as well, and we should consider the THIN

protocol as the outcome of these discussions.

At 02:36 98/02/24 +0900, Greg Shue wrote:

>Why? Because:


> - Microsoft is supporting the SCSI model for scanning,

> so the standard scanning solution is built around SBP-2


> - Microsoft and Apple both prefer SBP-2 for printing,

> so I prefer an SBP-2 based printing protocol.


I would also agree this may be a good reasoning from the

PC printing point of view.

-Differnt reasoning for differnt solutions....Both reasonable.

> - I want to support both PC printing and peer-to-peer

> interactions, so both protocols are going to exist.

> I don't see customers buying a printer which only

> supports peer-to-peer.

This is also VERY true. It's the manufacturer's responsibility

to avoid end-user confusion.

If $300 digital cameras don't support SBP-2 but support DPP, it's

our responsiblity to support it. Same opposite-wise.

My personal choice

"I may not love it, but I will use BOTH situation by situation!"

(I may have to implement AVC if that becomes necessary.)

That's why we proposed FDS right ?,

(Whatever protocol, we know where the printer is...)


<bigger>Atsushi Nakamura


BJ Technology Develpoment 22,

Canon Inc.

53 Imai Kami-cho

Nakahara-Ku, Kawasaki-shi

postal no. 211