the latest draft, LPR-LPD

[Joel Gartland <[e-mail]>]

	From [e-mail] Wed Mar 11 13:26:51 1992

Glenn, thaks for the notification about the latest draft of the
LPR-LPD RFC. It looks really good! It's nice to see some things
more explicitly defined, and some of the sparser explanations
fleshed out.

I've really only two objections to the RFC as I read it last night.
These are below, after the responses to your questions that I felt
I could give an informed response.

	Here are the questions that *I* need answers to, in order to finish 
	the LPR/LPD RFC.

	** Do we need to be more specific in the format or content of the 
	"Send Queue State" listing?
This would be really nice, if we could specify the format of the listing.
Of course, it will take forever for Berkeley LPD's do to this format....

	** Is the description for "Remove Jobs" (Section 5.5) accurate,
	especially w.r.t. wildcard deletes?
Yes, seems fine to me.

	** Are the failure codes for the second acknowledgement in "Receive
	Control File" and "Receive Data File" (Sections 6.2 and 6.3)
	correct and complete?
Yes, they agree with the original Berkeley implementation.

	** Is the wording for the 'v' print command (Section 8.11) correct?
Perfect. 

	** When a command or subcommand returns a failure status, does/should
	the daemon immediately close the connection?
I don't think this should be the case. It's possible the client could try and
send another job on the connection. For example, if the server replied "no
disk space", it is feasible a client may want to leave the TCP connection
open a few moments then try again. Unlikely, but feasible. Or to stretch
what is implied in the addition of the new command extensions (I feel these
are unecessary but since they are there) and how they might be used.
Cleint sends a job, datafile first (old style). Server, a "new server" 
has no disk space to queue data file, replies "not enough disk space". 
Client, also a new implementation, then tries to send the control file
first, whihc the server can spool as it is much smaller. Then the client
sends the data file, with the receive data file command (either with the
1179 way by sending length = 0, or using the new extension command) 
notifying the server to read until tcp connection closes. Server says fine,
starts reading the data file, printing as it receives the file.

So, in answer to the connection, I don't the server should close the 
connection when it returns a failure status.



Other reactions I have has to the RFC-to-be:

It's really good to see a difference between the long and short queue state
requests to defined.

On p. 7 you mention "only the agent is given, the implied command is to
delete the currently active job". I'd like to see "currently active job"
defined; is it the job currently printing?? or the one at the head of
the queue.

You also imply that you need the fully qualified Domain Name to verify
who can delete which jobs (i.e make sure the deletion request is from 
the same host who sent the job)/ This just isn't true. You can just
use the ip addr, as you always know who the TCP connection is from...
You just have to save it when you queue a job.


Lastly, I don't understand the need for the extensions you have added 
to RFC1179; that is the Receive Control File First and Receive Data
File of Unspecified Length. I understand why you want to add the
ability to send the control files first and a data file until the
connection is closed, but the ability to do this was in RFC1179,
in a straightforward manner. Implementation of this ability simply 
required keeping track of what files are received, which could be done
quite simply. Awhile back I implemented an LPD for DOS (about to be 
released) that could accept jobs either way (and an LPR to test 
it, too!), Cfile first or Dfiles first, only using the RFC1179 commands.
I feel that you are making relatively simply protocol and confusing it
a slightly. Thought the confusing is slight, I do not feel it's necessary.

         
Anyway, it does look good. Unfortunately, I won't be in San Diego to 
discuss it, but excepting the above, I think it's pretty close to as 
goodas it's going to get (that is without radically changing it from 
the original Berkeley non-spec.)

Hope this has been of some help.

Joel Gartland
FTP Software, Inc.