Subject: Re: IPP> Re: ADM - IPP Charter and Slot in Memphis

From: Keith Moore <[email-masked]>
Date: Thu, 06 Mar 1997 18:27:05 -0500

> Well, I guess I am going to hack off the IETF people but...
> 
> -- warning -- highly opinionated and caustic verbiage ahead
> 
> LPR is not a standard.  LPR is not as widely deployed 
> as many other protocols (pick Novell's PSERVER or RPRINTER
> or NetBEUI/SMB which are much more widely deployed) yet we 
> are making no effort to be compatible with those.  I think the
> request is unreasonable.  If a vendor wants to have a
> print server that supports both IPP and LPR as an inbound
> print mechanism -- great!  But to saddle IPP with LPR is 
> simply not reasonable.

LPR is not a standard, but it is widely available and both clients and
servers are implemented on every platform in existence.  The
alternatives you mention are platform-specific.  LPR is about the only
print protocol for which clients and servers are widely available for
almost every platform in existence.

If the WG feels that it's useful to show how to implement PSERVER,
RPRINTER, or SMB print protocols in terms of IPP, I'm sure IESG would
be happy to have those documents published as Informational RFCs.

There's no intent to "saddle IPP with LPR".  My idea is that the WG
should show how to implement LPR functionality on top of IPP (i.e. how
to translate LPR to IPP).  I agree that it wouldn't make any sense to
try to implement all of the IPP functionality over LPR, and there's no
requirement that this group do so.

Keith

---

From: "Steve Zilles" <[email-masked]>
Date: Thu, 06 Mar 1997 15:45:20 PST

> to translate LPR to IPP).

So, if I understand this correctly, you are asking we insure the
functionality present in LPR is not lost in going to IPP and that we
present an outline of one mapping of LPR functionality to IPP.

        Steve

---

From: Randy Turner <[email-masked]>
Date: Thu, 06 Mar 1997 16:27:32 -0800

It sounds to me like its not a loss of functionality that we are
trying to avoid, but the requirement appears to be explicit
interoperability between LPR clients and IPP servers. Wherein there
is some type of "gateway service" that maps LPR "config file"
statements to IPP attributes so that IPP servers emulate LPD
servers for potential LPR clients.

I am assuming that the gateway support only supports those 
"config file" options that are specified in RFC 1179, and that
any additional vendor-specific add-ons, no matter how prevalent
they may be, will not be mapped. These unknown attributes would
be ignored by IPP LPD-gateway services.

Randy

---

From: Keith Moore <[email-masked]>
Date: Thu, 06 Mar 1997 21:46:36 -0500

> present an outline of one mapping of LPR functionality to IPP.

yes, though perhaps more "specification" than "outline" and
closer to "the mapping" rather than "one mapping".

Keith

---

From: [email-masked]
Date: Fri, 07 Mar 1997 11:05:24 +0100

> present an outline of one mapping of LPR functionality to IPP. 

I believe this is true.

Examples of cases that should be handled, or guidance should exist:

- An LPR client talks to an LPR printer. You want to replace the printer
  with an IPP printer, but can't change the client.

- An LPR printer is absolutely necessary for some purpose, but the client
  that used to access it is being upgraded to IPP-only. What to do?

I believe both examples have several solutions, and probably easy ones,
but it's important to keep in mind.
Examples of things that may make trouble are if you paint yourself into
the corner where the client and the server of IPP have to negotiate about
the content type, and there is no "just spray the bits onto the printer;
it worked last week" option, or if you make it a requirement that every
pixel must go onto the page before an acknowledgement can be sent back
to the requester, even though the backend LPR-only printer has internal
storage and no way to show its internal queue.
(My HP Laserjet does that all the time....considerable time passes
between "queue empty" and the time I can fetch the printout....)

                      Harald A