Subject: Re: JMP> LPD Job submission mapping

From: JK Martin <[email-masked]>
Date: Tue, 11 Mar 1997 21:34:38 -0500 (EST)

Ron,

Since we live and breath (and die?) in the Unix environment every day,
perhaps we should respond to your question:

> My understanding is RFC 1179 specifies that the Data File and Control
> File may be sent in any order but most implementations send the Data
> File first.  I do not know of a method to reverse the order.  Maybe 
> a Unix expert can help.

Put simply, there is no real way to "reverse the order"...at least with
respect to the protocol.

The LPD protocol (aka RFC 1179) was NOT designed in a vacuum.  It was
designed as part and parcel of the LPD daemon environment; that environment
expected to FIRST spool all components of the submitted job (one or more
data files, followed by one control file).  So, if you have the luxury
of spooling all these components, then of course you can "reverse the order".

Of course, given the typical printer implementation (ie, no disk, etc),
this is not possible.

LPD would work SO WELL if only the control file were always transmitted
first.  If this were true, then the notion of extending LPD to improve
network printing would be a real possibility.

In the category of "Fun Things to Know and Forget":  in our travels,
only OS/2 2.1 sends the control file before the data file(s).  I wonder
how many LPD daemon systems mess up as a result of this...

	...jay

---

From: Patrick Powell <[email-masked]>
Date: Wed, 12 Mar 1997 07:24:10 -0800 (PST)

# The LPD protocol (aka RFC 1179) was NOT designed in a vacuum.  It was
# designed as part and parcel of the LPD daemon environment; that environment
# expected to FIRST spool all components of the submitted job (one or more
# data files, followed by one control file).  So, if you have the luxury
# of spooling all these components, then of course you can "reverse the order".

Umm... you are going to hate this, but actually LPR came first, RFC1179
was simply documenting LPR.  This is the same thing as RIP - RIP was
first, then the RIP RFC came much later;  note that the RFC had some
'do this as I say, not as I do' type things in it.

# In the category of "Fun Things to Know and Forget":  in our travels,
# only OS/2 2.1 sends the control file before the data file(s).  I
wonder # how many LPD daemon systems mess up as a result of this...

Ummm... I think you mean 'the broken vendor implementation of OS/2's
print spooler'... There are 2nd party spoolers that do it in EITHER
order, selectable by a run time switch.

Note that the BSD based LPR implementations usually send control files
first, the ones supplied with SYS III, send data files first,  and the
SYS VR4 seem to do what they damn well please from release to release.
In the PC world,  I have seen both - there is a drop in LPR client for
most Windows 3.1 WINSOCK support packages,  and I have seen both data
first or job first from different packages.

I have also noted that some printer manufacturers,  when the implement
LPD servers in their systems,  IGNORE the control file and use
'autosense' methods to determine what the file contents are.
I remember fighting with a XXX (censored) printer,  and trying to print
a students 'malformed postscript' file so I could take it away and look
at it and the printer kept locking up with 'postscript stack... '
messages printed on it.

Hey!  Why should we be surprised?  Given so much broken software out
there, most people try to be as accomodating as possible in what they
accept, and as restricted as possible in what they send.

Patrick Powell

#       ...jay