Here is some real information on the problems with implemenation of
LPD that we might want to include in our written explanation of why
IPP isn't just an extension of LPD.
Thanks to Jay for some real world information.
>Return-Path: <jmp-owner at pwg.org>
>Date: Tue, 11 Mar 1997 18:34:38 PST
>From: JK Martin <jkm at underscore.com>
>To: rbergma at dpc.com>Subject: Re: JMP> LPD Job submission mapping
>Cc: jmp at pwg.org>X-Sun-Charset: US-ASCII
>Sender: jmp-owner at pwg.org>>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...