Subject: IPP> About host-to-device protocol issue

From: Yuji SASAKI <[email-masked]>
Date: Fri, 10 Apr 1998 17:54:09 -0700

Dear all,

I attended the last IPP meeting at Portland, and I thought there is
terrible confusion about the host-to-device protocol. Although my
English capability is not very good, I saw a lot of people were
discussing about host-to-device protocol from different perspective.
Even listing up the requirment had took hours and hardly finished.

I want to make this clear...even if I'm misunderstanding about
"host to device" issue because of my English capability.

o Do we want to build a protocol which replaces IPP?

  I definately don't think so. IPP is a very good protocol for job
  submission use both on the Internet or Intranet. I think the
  "host-to-device" protocol would be more primitive, less inter-
  operable, less expandable but very lightweight and easy to implement
  protocol.

o Why do we build a new protocol for such use? We will be able to make
  IPP to have same function using with SNMP(PrinterMIB, Job MIB etc) or
  expanding IPP(adding notifications or device management capabilities).

o There are a lot of well-defined protocol which designed for
  "host-to-device" use, why do we want to build yet another one?

  With my understanding, PWG has never decided to build a new protocol
  for host-to-device use. What we have to do is clearify the "problem"
  in network printing environment(it does not mean IPP), and find the
  best way(develop a new protocol? pick one of them? or even do nothing
  would be best for us) to solve the problem. It is no use to discuess
  "IPP or NOT" without clearifing what problem sould be solved with.

o What is the "problem"?
  This is most difficult issue at all. Somebody(like me) think IPP is too
  heavy for cheap device, like $250 print server unit equipped with 16MHz
  80186 and 2Mbit(256Kbyte) ROM and RAM. But somebody else think it is not
  a problem, but providing two differnent protocols for network printing
  would be a deadly problem for PWG. Even somebody think the most important
  problem is why nobody recognize TIP/SI as the standard.

  I think almost everyone have problems in today's network printing
  environment, and wants to solve with ONE solution. Everybody is waiting
  for the ultimate network printing protocol...lightweight, easy to understand
  and implement, scaleable, flexible, expandable and also interpoerable,
  equipped with efficient directory scheme, runs on various physical layers...
  but I think it is virtually impossible to realize ONE solution which solves
  ALL problems. IPP is not also an ultimate printing protocol, it is just
  a better (but not the best) job submission protocol than regacy printing
  protocol such as LPR.

  I think the "host-to-device" protocol is something like "RS-232C over the
  network"(prease do not be persistant bout terminology...I know RS-232C
  is just a electorical/physical specification and not a protocol name,
  but it is practical and easy to understand my opinion).
  Today most of devices like printers, scanners, digital cameras could be
  connected to PCs with RS-232C serial wire, and most of customers satisfy
  with this even though RS-232C is far from the ultimate communication
  method. RS-232C is primitive, slow, ristricted to 1-to-1 connection,
  ristricted up to 15m, no interoperability, poor compatibility(Baud rate?
  Stop Bit? no way!), many unnessasary pins (RTS/CTS? CD/RI? what the heck
  are them?) but it is very easy to implement and it works at all.

  I think what should we do about "host-to-device" issue is to provide
  a good solution something like "RS-232C over the network".
  I know there are many protocols like that...you can use TELNET, bi-
  directional LPR, TIP/SI, even TFTP can be used, perhaps raw-TCP-socket
  is good solution , or you can modify IPP to have such capabilities.
  But what is the best solution for PWG? I think this is the issue what we
  have to discuess.

--------
Yuji Sasaki
Company E-Mail :[email-masked]
Personal E-Mail:[email-masked]
Nifty-Serve    :[email-masked]