the latest draft, LPR-LPD
Joel Gartland <joel@ftp.com> Fri, 13 March 1992 23:28 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00895; 13 Mar 92 18:28 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06182; 13 Mar 92 18:29 EST
Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa06178; 13 Mar 92 18:29 EST
Received: by inet-gw-1.pa.dec.com; id AA01479; Fri, 13 Mar 92 15:29:44 -0800
Received: by nsl.pa.dec.com; id AA14198; Fri, 13 Mar 92 15:03:56 -0800
Received: by nsl.pa.dec.com; id AA14194; Fri, 13 Mar 92 15:03:21 -0800
Received: by inet-gw-1.pa.dec.com; id AA00196; Fri, 13 Mar 92 15:03:14 -0800
Received: by ftp.com id AA02245; Fri, 13 Mar 92 18:03:48 -0500
Date: Fri, 13 Mar 1992 18:03:48 -0500
From: Joel Gartland <joel@ftp.com>
Message-Id: <9203132303.AA02245@ftp.com>
To: print-wg@pa.dec.com
Subject: the latest draft, LPR-LPD
From trewitt@pa.dec.com 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.
- the latest draft, LPR-LPD Joel Gartland
- Re: the latest draft, LPR-LPD Glenn Trewitt
- Re: the latest draft, LPR-LPD leo j mclaughlin iii
- Re: the latest draft, LPR-LPD Bruce Crabill
- Re: the latest draft, LPR-LPD leo j mclaughlin iii
- Re: the latest draft, LPR-LPD Bruce Crabill
- Re: the latest draft, LPR-LPD Glenn Trewitt