Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04265; 11 Mar 92 13:25 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17687; 11 Mar 92 13:25 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa17680; 11 Mar 92 13:25 EST Received: by inet-gw-1.pa.dec.com; id AA27250; Wed, 11 Mar 92 10:25:43 -0800 Received: by nsl.pa.dec.com; id AA15636; Wed, 11 Mar 92 09:44:24 -0800 Received: by nsl.pa.dec.com; id AA15630; Wed, 11 Mar 92 09:44:20 -0800 Received: by miasma.pa.dec.com; id AA15973; Wed, 11 Mar 92 09:42:38 -0800 Message-Id: <9203111742.AA15973@miasma.pa.dec.com> To: print-wg@pa.dec.com Cc: Glenn Trewitt Subject: Network Printing Working Group meeting Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Wed, 11 Mar 92 09:42:38 -0800 From: Glenn Trewitt X-Mts: smtp The Network Printing Working group will be meeting in San Diego on Monday from 1:30 to 3:30 in the afternoon. I will send out a detailed agenda later today, but here is the general idea: * Finish off the lpr/lpd spec and answer all outstanding questions. * Figure out what we want to do with the RFC: * Leave it as "informational". * Put it on the standards track. This requires implementation, etc. Are there any implementors out there? * Figure out what (if anything) we do next * Is there interest in the WG for the Printer Access Protocol? It feels a bit like I've been pushing a limp rope on this one. - Glenn   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04780; 11 Mar 92 21:35 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06609; 11 Mar 92 21:36 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa06592; 11 Mar 92 21:35 EST Received: by inet-gw-1.pa.dec.com; id AA19091; Wed, 11 Mar 92 18:34:49 -0800 Received: by nsl.pa.dec.com; id AA22224; Wed, 11 Mar 92 18:06:45 -0800 Received: by nsl.pa.dec.com; id AA22218; Wed, 11 Mar 92 18:06:42 -0800 Received: by miasma.pa.dec.com; id AA16767; Wed, 11 Mar 92 18:04:59 -0800 Message-Id: <9203120204.AA16767@miasma.pa.dec.com> To: print-wg@pa.dec.com Cc: Glenn Trewitt Subject: Network Printing Working Group -- new files and agenda Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Wed, 11 Mar 92 18:04:59 -0800 From: Glenn Trewitt X-Mts: smtp The Network Printing Working group will be meeting in San Diego on Monday from 1:30 to 3:30 in the afternoon. Here is the agenda: **** Finish off the lpr/lpd spec and answer outstanding questions. I've listed the specific questions that I need answered at the end of this message. This should be short. **** Figure out what we want to do with the RFC: * Leave it as "informational". * Put it on the standards track. This requires implementation, etc. Are there any implementors out there? (I hope that we can get Russ Hobby to explain what's involved here.) **** Figure out what (if anything) we do next * Is there interest in the WG for the Printer Access Protocol? It feels a bit like I've been pushing a limp rope on this one. * Do we have the right set of people to do a good job of designing and implementing a replacement for lpr/lpd? The following new files are available: new-lpd.txt new-lpd.ps The current draft of the LPR/LPD protocol spec. DEC-cpap.txt DEC-cpap.ps This document describes the "Printer Access Protcol" that has been submitted for consideration by the WG. A lot of work has been done to make this more of a standalone document, and to feel more like an RFC. They may be retrieved by anonymous FTP from gatekeeper.dec.com, in ~ftp/pub/net/info/ietf/print-wg. Here are the questions that *I* need answers to, in order to finish the LPR/LPD RFC. ** In text data files, do we accept any line endings besides LF? ** When a command or subcommand returns a failure status, does/should the daemon immediately close the connection? ** Do we need to be more specific in the format or content of the "Send Queue State" listing? ** Is the description for "Remove Jobs" (Section 5.5) accurate, especially w.r.t. wildcard deletes? ** 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? ** Is the wording for the 'v' print command (Section 8.11) correct? ** Were we removing the Palladium ('z' print command)? - Glenn   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00977; 12 Mar 92 18:26 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29288; 12 Mar 92 18:26 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa29280; 12 Mar 92 18:26 EST Received: by inet-gw-1.pa.dec.com; id AA13881; Thu, 12 Mar 92 15:27:33 -0800 Received: by nsl.pa.dec.com; id AA01357; Thu, 12 Mar 92 14:26:05 -0800 Received: by nsl.pa.dec.com; id AA01351; Thu, 12 Mar 92 14:26:00 -0800 Received: by miasma.pa.dec.com; id AA17797; Thu, 12 Mar 92 14:24:16 -0800 Message-Id: <9203122224.AA17797@miasma.pa.dec.com> To: print-wg@pa.dec.com Cc: Glenn Trewitt Subject: LPR/LPD: Extending the Control File Command Set Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Thu, 12 Mar 92 14:24:15 -0800 From: Glenn Trewitt X-Mts: smtp There have been some discussions at the meetings about how to extend the control file command set in a reasonable way. What about the following? I will update new-lpd.{ps,txt} shortly. - Glenn 7.1 Extending the Control File Command Set The commands described here, except for 'k', 'x' and 'X', are the ones defined by the original BSD LPR/LPD implementation. Many other control file commands have been implemented in other, later versions. We will not attempt to account for them here since, in some cases, that would require us to "bless" one usage over another. The "address space" of single printable characters is not large enough for effective extensions. For this reason, we allow the definitions of the remaining single-character commands to remain undefined and therefore, implementation-dependent. We recommend that control file commands that are not understand by a printing daemon be logged with other job messages and ignored. Processing of the job should proceed on a "best-effort" basis. The 'X' and 'x' commands are defined to allow command extension, providing a much larger set of available commands. We do not define any naming authority, but rely on implementors communicating among themselves and documenting what they've done to provide interoperability. The larger command space should reduce the likelyhood of collisions. 8.17 X - Extended Print Option +---+------ +----+------------+----+ | X | ident | SP | options... | LF | +---+-------+----+------------+----+ Command code 'X' Operand 1 Extension identifier Remainder Extension-specific options This command allows for print option extensions to be made to cooperating clients and servers. The extension identifier is chosen by the implementor of the extension. It should be expressive enough to be distinct from other identifiers that might be chosen by other implementors. The remainder of the line, after the space, may consist of any characters except LF. The interpretation of the options is up to the implementor of the option. If many extensions are to be made, we recommend that a single extension identifier be chosen, with the For example, suppose that an implementation wishes to use LPR/LPD to transport ISO Document Printing Architecture print jobs. ISO DPA has dozens of attributes that may be chosen. Rather than clutter up the extension name space with these attribute names, they might choose an extension identifier "ISO-DPA" and let the remainder of the line be white-space separated attribute-value pairs. The implementation of the 'X' command and any identifiers by a daemon is optional. Extensions that are not recognized should be logged with other job messages and ignored. 10.12 x - Extended Print Command +---+------ +----+------+----+ | x | ident | SP | file | LF | +---+-------+----+------+----+ Command code 'x' Operand 1 Extension identifier Operand 2 File to print This command allows for file type extensions to be made to cooperating clients and servers. The extension identifier is chosen by the implementor of the extension. It should be expressive enough to be distinct from other identifiers that might be chosen by other implementors. For example, suppose someone wants to be able to spool "TIFF" files directly, and have the system do the conversion. The extension identifier "tiff" might be chosen: xtiff dfA123user.bigco.com The implementation of the 'x' command and any identifiers by a daemon is optional. Extensions that are not recognized should be logged with other job messages and ignored. This will result in the file not being printed.   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 92 18:03:48 -0500 From: Joel Gartland 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.   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00193; 16 Mar 92 13:27 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00918; 16 Mar 92 13:28 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa00879; 16 Mar 92 13:28 EST Received: by inet-gw-1.pa.dec.com; id AA13197; Mon, 16 Mar 92 10:26:16 -0800 Received: by nsl.pa.dec.com; id AA10993; Mon, 16 Mar 92 09:46:17 -0800 Received: by nsl.pa.dec.com; id AA10985; Mon, 16 Mar 92 09:45:55 -0800 Message-Id: <9203161745.AA10985@nsl.pa.dec.com> To: Joel Gartland Cc: print-wg@pa.dec.com, Glenn Trewitt Subject: Re: the latest draft, LPR-LPD In-Reply-To: Your message of Fri, 13 Mar 92 18:03:48 -0500. <9203132303.AA02245@ftp.com> Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Mon, 16 Mar 92 09:45:55 -0800 From: Glenn Trewitt X-Mts: smtp The reason for the new send* commands was to allow interoperability with old agents. With 1179, there was no way for an agent to communicate with a daemon and determine whether it was safe to use the "extensions" specified in 1179. For example: A new client sends the control file first. -> An old daemon will immediately try to print the job, and lose big. A new client attempts to use the "0" length encoding. -> An old daemon will spool a zero-length data file and get a non-null sync byte, terminating the session and job. 1179 is completely broken, as far as interoperability goes. The new RFC does not allow the 0-length encoding or any other changes to the semantics of the existing commands. - Glenn   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00244; 16 Mar 92 15:22 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04933; 16 Mar 92 15:23 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa04929; 16 Mar 92 15:23 EST Received: by inet-gw-1.pa.dec.com; id AA21107; Mon, 16 Mar 92 12:24:07 -0800 Received: by nsl.pa.dec.com; id AA00573; Mon, 16 Mar 92 11:36:15 -0800 Received: by nsl.pa.dec.com; id AA00567; Mon, 16 Mar 92 11:35:59 -0800 Received: by inet-gw-1.pa.dec.com; id AA18052; Mon, 16 Mar 92 11:35:39 -0800 Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA29926; Mon, 16 Mar 92 14:36:31 -0500 Date: Mon, 16 Mar 92 14:36:31 -0500 Message-Id: <9203161936.AA29926@ftp.com> To: trewitt@pa.dec.com Subject: Re: the latest draft, LPR-LPD From: leo j mclaughlin iii Reply-To: ljm@ftp.com Cc: joel@ftp.com, print-wg@pa.dec.com, trewitt@pa.dec.com Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com > >The reason for the new send* commands was to allow interoperability >with old agents. With 1179, there was no way for an agent to >communicate with a daemon and determine whether it was safe to use the >"extensions" specified in 1179.... > Well...if you have an only new client and an only old server the failure mode in both 1179 and the new RFC is the same -- you can't print. The advantage of the draft mechanism is that unlike 1179 clients, the new specification allows for draft clients to dynamically adapt to old or new servers. > >1179 is completely broken, as far as interoperability goes. The new >RFC does not allow the 0-length encoding or any other changes to the >semantics of the existing commands. > Then the new RFC is even more broken as far as interoperability goes. If the number of email messages I have recieved asking questions about 1179 is any indication, a lot of folk out there have implemented 1179 compliant lpr clients. For the new RFC to break these existing implementations is a rather large departure from normal protocol development. enjoy, leo j mclaughlin iii ljm@ftp.com   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00371; 17 Mar 92 0:18 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19293; 17 Mar 92 0:19 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa19289; 17 Mar 92 0:19 EST Received: by inet-gw-1.pa.dec.com; id AA24167; Mon, 16 Mar 92 21:19:47 -0800 Received: by nsl.pa.dec.com; id AA07555; Mon, 16 Mar 92 20:28:45 -0800 Received: by nsl.pa.dec.com; id AA07551; Mon, 16 Mar 92 20:28:42 -0800 Received: by inet-gw-1.pa.dec.com; id AA21879; Mon, 16 Mar 92 20:28:33 -0800 Message-Id: <9203170428.AA21879@inet-gw-1.pa.dec.com> Received: by UMDD.UMD.EDU id 6219 ; 16 Mar 92 23:30:25 EST Received: by UMDD (Mailer R2.07) id 6219; Mon, 16 Mar 92 23:30:24 EST Date: Mon, 16 Mar 92 23:25:43 EST From: Bruce Crabill Subject: Re: the latest draft, LPR-LPD In-Reply-To: Message received on Mon, 16 Mar 92 15:36:06 EST To: print-wg@pa.dec.com It was a real injustice to the Internet community that RFC-1179 ever got out there in the first place. However, just because it is out there, is no excuse to perpetuate a bad idea. After all, it wasn't on the standards track. Interoperability is important. Bruce   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00306; 18 Mar 92 13:56 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17764; 18 Mar 92 13:57 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa17636; 18 Mar 92 13:54 EST Received: by inet-gw-1.pa.dec.com; id AA27584; Wed, 18 Mar 92 10:45:30 -0800 Received: by nsl.pa.dec.com; id AA25422; Wed, 18 Mar 92 09:21:16 -0800 Received: by nsl.pa.dec.com; id AA25387; Wed, 18 Mar 92 09:19:03 -0800 Received: by inet-gw-1.pa.dec.com; id AA23129; Wed, 18 Mar 92 09:16:45 -0800 Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA17916; Wed, 18 Mar 92 12:17:22 -0500 Date: Wed, 18 Mar 92 12:17:22 -0500 Message-Id: <9203181717.AA17916@ftp.com> To: BRUCE@umdd.umd.edu Subject: Re: the latest draft, LPR-LPD From: leo j mclaughlin iii Reply-To: ljm@ftp.com Cc: print-wg@pa.dec.com Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com > >It was a real injustice to the Internet community that RFC-1179 ever got out >there in the first place. However, just because it is out there, is no >excuse to perpetuate a bad idea.... No, but because it is working better than the BSD 4.3 code for over 100,000 users is an excellent reason to perpetuate an idea.... >After all, it wasn't on the standards track. Nor will the new LPR rfc. Nor is X. Nor is NFS. Most of the traffic in the Internet universe are defacto standards, not standards by fiat. >Interoperability is important. Full agreement. RFC 1179 was fully interoperable with the BSD 4.3 code. It is essential that RFC-XXXX be fully interoperable with 1179 and 4.3. enjoy, leo j mclaughlin iii ljm@ftp.com   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00337; 18 Mar 92 15:40 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21711; 18 Mar 92 15:42 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa21691; 18 Mar 92 15:41 EST Received: by inet-gw-1.pa.dec.com; id AA02120; Wed, 18 Mar 92 12:34:57 -0800 Received: by nsl.pa.dec.com; id AA27471; Wed, 18 Mar 92 11:44:28 -0800 Received: by nsl.pa.dec.com; id AA27467; Wed, 18 Mar 92 11:43:57 -0800 Received: by inet-gw-1.pa.dec.com; id AA00166; Wed, 18 Mar 92 11:42:29 -0800 Message-Id: <9203181942.AA00166@inet-gw-1.pa.dec.com> Received: by UMDD.UMD.EDU id 0237 ; 18 Mar 92 14:44:01 EST Received: by UMDD (Mailer R2.07) id 0237; Wed, 18 Mar 92 14:43:59 EST Date: Wed, 18 Mar 92 14:35:00 EST From: Bruce Crabill Subject: Re: the latest draft, LPR-LPD In-Reply-To: Message received on Wed, 18 Mar 92 12:18:23 EST To: print-wg@pa.dec.com >>Interoperability is important. > >Full agreement. RFC 1179 was fully interoperable with the BSD 4.3 code. >It is essential that RFC-XXXX be fully interoperable with 1179 and 4.3. Sorry, I disagree. If a person picked up RFC 1179 and not ever having worked with a BSD 4.3 LPD tried to implement an LPR according to the RFC 1179 spec would end up with a LPR that would not interoperate with BSD 4.3 machines. It might very well work with the code that company sells, but RFC 1179 clearly states: "The Berkeley versions of the Unix(tm) operating system provide line printer spooling with a collection of programs: lpr (assign to queue), lpq (display the queue), lprm (remove from queue), and lpc (control the queue). These programs interact with an autonomous process called the line printer daemon. This RFC describes the protocols with which a line printer daemon client may control printing." In fact, it did not document the protocol as used by BSD. Please don't think that I'm saying that the BSD LPR protocol is perfect as is and doesn't need improvement, the operating system environment that I program in needs some of those enhancements that you made, however, you can't claim that RFC 1179 documented the BSD protocol when in reality it didn't. Bruce   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00343; 18 Mar 92 16:47 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23757; 18 Mar 92 16:48 EST Received: from inet-gw-1.pa.dec.com by NRI.Reston.VA.US id aa23731; 18 Mar 92 16:47 EST Received: by inet-gw-1.pa.dec.com; id AA04152; Wed, 18 Mar 92 13:39:31 -0800 Received: by nsl.pa.dec.com; id AA28381; Wed, 18 Mar 92 13:04:20 -0800 Received: by nsl.pa.dec.com; id AA28360; Wed, 18 Mar 92 13:02:55 -0800 Message-Id: <9203182102.AA28360@nsl.pa.dec.com> To: Bruce Crabill Cc: print-wg@pa.dec.com, Glenn Trewitt Subject: Re: the latest draft, LPR-LPD In-Reply-To: Your message of Wed, 18 Mar 92 14:35:00 -0500. <9203181942.AA00166@inet-gw-1.pa.dec.com> Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Wed, 18 Mar 92 13:02:54 -0800 From: Glenn Trewitt X-Mts: smtp The agreement we reached in the meeting was that interopability issues with 1179 would be addressed in a separate section. It would instruct about how a "new" daemon could survive an interaction with an RFC 1179 daemon. - Glenn   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06564; 22 Jul 92 22:05 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06560; 22 Jul 92 22:05 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa23034; 22 Jul 92 22:08 EDT Received: by inet-gw-2.pa.dec.com; id AA25335; Wed, 22 Jul 92 19:08:10 -0700 Received: by nsl.pa.dec.com; id AA25143; Wed, 22 Jul 92 18:52:48 -0700 Received: by nsl.pa.dec.com; id AA25137; Wed, 22 Jul 92 18:52:42 -0700 Received: by inet-gw-1.pa.dec.com; id AA26793; Wed, 22 Jul 92 18:52:33 -0700 Message-Id: <9207230152.AA26793@inet-gw-1.pa.dec.com> Date: Wed, 22 Jul 92 21:48:41 EDT From: Brad Clements To: Glenn Trewitt Cc: print-wg@pa.dec.com Subject: printing WG, is this group doing anything? Subject says it all. Has this group done anything since last year? Whats the status of CPAP (or any other protocol) proposal? Speaking of CPAP, does anyone have a `client' implementation and a server implementation to test against? Has any other vendor made a proposal on this subject? With the NPA having finalized their IO spec, I'd like to see this group make some progress too. Is there something I can do? | Brad Clements, CCP bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03208; 23 Jul 92 11:04 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03204; 23 Jul 92 11:04 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa16488; 23 Jul 92 11:07 EDT Received: by inet-gw-2.pa.dec.com; id AA02095; Thu, 23 Jul 92 08:07:37 -0700 Received: by nsl.pa.dec.com; id AA14601; Thu, 23 Jul 92 08:04:40 -0700 Received: by nsl.pa.dec.com; id AA14597; Thu, 23 Jul 92 08:04:39 -0700 Received: by inet-gw-2.pa.dec.com; id AA01933; Thu, 23 Jul 92 08:04:37 -0700 Received: from next-s.lanl.gov by p.lanl.gov (5.65/1.14)id AA14232; Thu, 23 Jul 92 09:04:31 -0600 Received: by next-s.lanl.gov (NeXT-1.0 (From Sendmail 5.52)/5.17)id AA06832; Thu, 23 Jul 92 08:58:35 MDT Date: Thu, 23 Jul 92 08:58:35 MDT From: Steve Smith Message-Id: <9207231458.AA06832@next-s.lanl.gov> Received: by NeXT Mailer (1.62) To: Brad Clements Subject: Re: printing WG, is this group doing anything? Cc: Glenn Trewitt , print-wg@pa.dec.com Brad, Glenn, IETF-WG, I second the question. I joined this list almost a year ago with the expectation that I would be finding some action. In the absence of "standards" action, we are extending de facto standards with no strong sense of the larger community. How many people on this list? How many of those are invested in full-on network printing models? What do we/you consider full-on models. Peers in this area are hard to find... I presume that this crowd should have a few with the interest, and perhaps even charter to work seriously on this problem. I believe I would have the support here to build a system to a spec that meets many of our requirements. I will post a summary of my position to print-wg "soon". Brad, thanks for the wakeup call. I wish I had sent one out some time back. However, being new to this, I wanted to wait for someone else to stir up the action. Steve Smith sas@lanl.gov Pages project leader Computing and Communications division Los Alamos National Laboratory (505) 667-6771   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04309; 23 Jul 92 13:04 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04305; 23 Jul 92 13:04 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa21322; 23 Jul 92 13:07 EDT Received: by inet-gw-2.pa.dec.com; id AA08268; Thu, 23 Jul 92 10:07:47 -0700 Received: by nsl.pa.dec.com; id AA15567; Thu, 23 Jul 92 09:57:39 -0700 Received: by nsl.pa.dec.com; id AA15563; Thu, 23 Jul 92 09:57:38 -0700 Received: by inet-gw-1.pa.dec.com; id AA00539; Thu, 23 Jul 92 09:57:37 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for trewitt@pa.dec.com; Thu, 23 Jul 92 12:57:26 EDT Received: via switchmail; Thu, 23 Jul 1992 12:57:22 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 23 Jul 1992 12:56:53 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 23 Jul 1992 12:56:47 -0400 (EDT) Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.cortland.andrew.cmu.edu.pmax.ul4 via MS.5.6.cortland.andrew.cmu.edu.pmax_ul4; Thu, 23 Jul 1992 12:56:33 -0400 (EDT) Message-Id: Date: Thu, 23 Jul 1992 12:56:33 -0400 (EDT) From: Wallace Colyer To: print-wg@pa.dec.com, Steve Smith Subject: Re: printing WG, is this group doing anything? Cc: Glenn Trewitt , print-wg@pa.dec.com In-Reply-To: <9207231458.AA06832@next-s.lanl.gov> References: <9207231458.AA06832@next-s.lanl.gov> I'll third the question. We are beginning a project to develop a common printing system for our different computing groups. We would be very interested in working with other groups. What is a full-on model? Is this addressing pure network printers? -Wallace   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04309; 23 Jul 92 13:04 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04305; 23 Jul 92 13:04 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa21322; 23 Jul 92 13:07 EDT Received: by inet-gw-2.pa.dec.com; id AA08268; Thu, 23 Jul 92 10:07:47 -0700 Received: by nsl.pa.dec.com; id AA15567; Thu, 23 Jul 92 09:57:39 -0700 Received: by nsl.pa.dec.com; id AA15563; Thu, 23 Jul 92 09:57:38 -0700 Received: by inet-gw-1.pa.dec.com; id AA00539; Thu, 23 Jul 92 09:57:37 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for trewitt@pa.dec.com; Thu, 23 Jul 92 12:57:26 EDT Received: via switchmail; Thu, 23 Jul 1992 12:57:22 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 23 Jul 1992 12:56:53 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 23 Jul 1992 12:56:47 -0400 (EDT) Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.cortland.andrew.cmu.edu.pmax.ul4 via MS.5.6.cortland.andrew.cmu.edu.pmax_ul4; Thu, 23 Jul 1992 12:56:33 -0400 (EDT) Message-Id: Date: Thu, 23 Jul 1992 12:56:33 -0400 (EDT) From: Wallace Colyer To: print-wg@pa.dec.com, Steve Smith Subject: Re: printing WG, is this group doing anything? Cc: Glenn Trewitt , print-wg@pa.dec.com In-Reply-To: <9207231458.AA06832@next-s.lanl.gov> References: <9207231458.AA06832@next-s.lanl.gov> I'll third the question. We are beginning a project to develop a common printing system for our different computing groups. We would be very interested in working with other groups. What is a full-on model? Is this addressing pure network printers? -Wallace   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05982; 23 Jul 92 15:07 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab05978; 23 Jul 92 15:07 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa26419; 23 Jul 92 15:07 EDT Received: by inet-gw-2.pa.dec.com; id AA14942; Thu, 23 Jul 92 12:07:33 -0700 Received: by nsl.pa.dec.com; id AA16682; Thu, 23 Jul 92 11:18:20 -0700 Received: by nsl.pa.dec.com; id AA16677; Thu, 23 Jul 92 11:18:19 -0700 Received: by miasma.pa.dec.com; id AA06645; Thu, 23 Jul 92 11:18:17 -0700 Message-Id: <9207231818.AA06645@miasma.pa.dec.com> To: print-wg@pa.dec.com Cc: Glenn Trewitt Subject: Re: printing WG, is this group doing anything? Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Thu, 23 Jul 92 11:18:16 -0700 From: Glenn Trewitt X-Mts: smtp I'll fourth the question... Oh, wait, I guess the buck stops here. Here's the situation. First of all, I've been very busy, and haven't had time to devote the attention to this group needs in order to have it produce things. Second of all, I do not (and never claimed to) have the time or resources to do development on the things we discuss. I have viewed my role as a moderator/secretary/writer for our work. I have clearly not provided the carrot or whip necessary to spur us on. So, if anybody has the energy to devote to chairing this group, I hereby offer to step down, right after we (I) finish the last edits to LPR/LPD and get it submitted as "informational". Here's how I see the status of the various (potential) projects: LPR/LPD: I need to integrate the edits we agree to at the last meeting. Hopefully we can get it out the door. CPAP (Printer Access Protocol): The fellow who was working on RFC-izing this (Jim Jones) has taken early retirement. It's not clear that that group has the energy to invest in the back-and-forth that's necessary for us as a working group to reach concensus. I've suggested that they take what they have and submit it as an informational RFC, that documents existing practice. For more information about CPAP, talk to Tom Powers Tom is on this list. LPR/LPD replacement: Palladium is the cannonical possibility, which no one in the group has been interested in. Also, Brad Clements has submitted an SMTP-like spooling protocol. On-Demand Publishing: I talked to Scott Bradner at the close of the San Diego IETF and he mentioned a project that is big and needs doing. Provide protocols to allow a person "P" to electronically request a copy of document "X" to be printed at print shop "S". (e.g., A set of documents for a course.) These documents might be VERY large; many gigabytes, so conventional spooling techniques wouldn't work. There would be a lot of "third-party" negotions: P asks S to get document X. S causes P to be charged any copyright fees for X. etc. This would require a lot of integration of interesting technologies: authentication, bulk transfer, etc. NPA: A new development in the network printing arena is the "Network Printing Alliance", which has generated a spec. for what they call the "Bi-Di Printer Protocol". The group is tied into IEEE. The protocol provides services very similar to CPAP, but I don't think that they go as far as CPAP. The main thing that troubles me is that the protocol fiddles with bits *everywhere*. Beyond the message header, every command has a distinct format and most of them employ bit fields. Although this is a matter of personal preference, it looks like the protocol came from a big committee. There is no "art" in it. - Glenn   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06564; 23 Jul 92 16:07 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06560; 23 Jul 92 16:07 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa29425; 23 Jul 92 16:07 EDT Received: by inet-gw-2.pa.dec.com; id AA18346; Thu, 23 Jul 92 13:07:19 -0700 Received: by nsl.pa.dec.com; id AA18368; Thu, 23 Jul 92 12:30:02 -0700 Received: by nsl.pa.dec.com; id AA18361; Thu, 23 Jul 92 12:30:01 -0700 Received: by inet-gw-1.pa.dec.com; id AA13216; Thu, 23 Jul 92 12:29:59 -0700 Message-Id: <9207231929.AA13216@inet-gw-1.pa.dec.com> Received: by UMDD.UMD.EDU id 0959 ; 23 Jul 92 15:30:44 EDT Received: by UMDD (Mailer R2.08 PTF008) id 0959; Thu, 23 Jul 92 15:30:44 EDT Date: Thu, 23 Jul 92 15:28:19 EDT From: Bruce Crabill Subject: Re: printing WG, is this group doing anything? In-Reply-To: Message received on Thu, 23 Jul 92 15:15:25 EDT To: print-wg@pa.dec.com The University of Maryland has previously submitted to this working group a LPD/LPR replacement protocol that we would also like to have considered. Bruce   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06619; 23 Jul 92 16:09 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06612; 23 Jul 92 16:09 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa29527; 23 Jul 92 16:09 EDT Received: by inet-gw-2.pa.dec.com; id AA18470; Thu, 23 Jul 92 13:09:06 -0700 Received: by nsl.pa.dec.com; id AA18427; Thu, 23 Jul 92 12:41:26 -0700 Received: by nsl.pa.dec.com; id AA18422; Thu, 23 Jul 92 12:41:24 -0700 Received: by inet-gw-1.pa.dec.com; id AA14100; Thu, 23 Jul 92 12:41:16 -0700 Message-Id: <9207231941.AA14100@inet-gw-1.pa.dec.com> Date: Thu, 23 Jul 92 15:37:29 EDT From: Brad Clements To: Glenn Trewitt Cc: print-wg@pa.dec.com, Glenn Trewitt Subject: Re: printing WG, is this group doing anything? Gee, I don't recall suggesting any protocol, let alone something like SMTP. -- Isn't the philosophy of the IETF now to have two separate implementations of a protocol before accepting a proposal for that protocol? -- I ask again about CPAP. Palladium I've seen, a little. As far as the other document delivery service, well that sounds interesting, but does it fall within the scope of this group? Do we need to start over again? Are the original goals of this group in alignment with the current members? | Brad Clements, CCP bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06680; 23 Jul 92 16:10 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06676; 23 Jul 92 16:10 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa29620; 23 Jul 92 16:10 EDT Received: by inet-gw-2.pa.dec.com; id AA18545; Thu, 23 Jul 92 13:10:33 -0700 Received: by nsl.pa.dec.com; id AA18479; Thu, 23 Jul 92 12:52:34 -0700 Received: by nsl.pa.dec.com; id AA18475; Thu, 23 Jul 92 12:52:32 -0700 Received: by uucp-gw-2.pa.dec.com; id AA24299; Thu, 23 Jul 92 12:52:30 -0700 Date: Thu, 23 Jul 92 15:52:15 -0400 From: Scott Bradner Message-Id: <9207231952.AA29410@hsdndev.harvard.edu> To: print-wg@pa.dec.com Subject: Re: printing WG, is this group doing anything? Cc: trewitt@pa.dec.com re: on-demand printing I should have a new draft of the proposal within a month or so if anyone would like top see it. Scott   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06726; 23 Jul 92 16:12 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06722; 23 Jul 92 16:12 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa29703; 23 Jul 92 16:12 EDT Received: by inet-gw-2.pa.dec.com; id AA18659; Thu, 23 Jul 92 13:12:16 -0700 Received: by nsl.pa.dec.com; id AA18173; Thu, 23 Jul 92 12:19:32 -0700 Received: by nsl.pa.dec.com; id AA18169; Thu, 23 Jul 92 12:19:30 -0700 Received: by inet-gw-2.pa.dec.com; id AA15656; Thu, 23 Jul 92 12:19:28 -0700 Received: from next-s.lanl.gov by p.lanl.gov (5.65/1.14)id AA00121; Thu, 23 Jul 92 13:18:48 -0600 Received: by next-s.lanl.gov (NeXT-1.0 (From Sendmail 5.52)/5.17)id AA07009; Thu, 23 Jul 92 13:12:33 MDT Date: Thu, 23 Jul 92 13:12:33 MDT From: Steve Smith Message-Id: <9207231912.AA07009@next-s.lanl.gov> Received: by NeXT Mailer (1.62) To: print-wg@pa.dec.com Subject: Requirements for a network printing environment print-wg I lead the development of a moderately complex system for providing output services to a moderately large networked customer base. We have an existing infrastructure which is overdue for an overhaul. I am working on strategy plans and requirements for such a system. I would like to develop a model with as large of scope as possible and then implement whatever subset vision and resources will allow but "within the context" of a larger, more general model. The scope of the model I refer to is a "cooperative, distributed printing environment" which includes the issues of automatic brokering of services between environments with automatic resolution of all the attendant issues of accounting, quality control and scheduling. A subset of this model, more likely to be of interest to others would be a "network printing environment" which is approximately what we find various systems evolving toward. Requirements for a network printing environment- Ubiquity - Transparency - Extendibility - Generality - Interoperability - Reliability - Printing should be taken to mean the recording of information on physical media. In general it means images on paper or film but is not neccesarily limited to this definition. Ubiquity - The environment should reflect the relative ubiquity of image formats, computing environments, networking environments and output equipment. Transparency - Access to printing resources should be transparent. Printing a file at a remote location should be as easy as printing it in your office. Printing a sun raster file should be as easy as printing an ASCII text file. Printing any image on a 36" plotter should be as easy as printing it on a laser writer. The incremental requirements to a client to use a "different" service from the one they are accustomed to should be only those directly related to the service. A user of a remote printer needs to know where to pick up output or how to have it delivered and the expected schedule. Someone printing an image designed for a 35mm slide on a color viewgraph needs to understand the difference in media quality. Someone logged into a Unix machine from their Mac needs to understand the Unix environment and that lpr is required to print something. But no more. Extendability - The lpr suite of tools was designed literally for line printers but was quickly extended to include electrostatics and ultimately many imaging devices. lpr is extendible but has been extended far past the paradigm it originally represented. It should be assumed that whatever questions we ask today will have increasingly complex answers as they evolve and that we have not asked all the questions today. There are many examples in existence today that fit the requirement of "imaging information on physical media" that are not taken into account in current models. For example, the requirements of rendering 3D models into 3D models such as by using holography or stereolithography are like not to be addressed by any "practical" system, yet are likely to be viable technologies before the systems being designed to day will be replaced. The requirements of movies, multimedia, hyper-documents, 3D, and many other areas are not critical today but may dominate in the future. A model that anticipates such things but doesn't try to address them in detail is likely to be much more viable than one which ignores them or solve them in detail would. Generality Each element in the environment can be designed to "just meet" requirements. It can also be designed to embrace a larger model, a larger view of the problem at hand. Many of the issues of extendibility are resolved naturally by simply designing and implementing to the most general model available. Spooling, queueing, scheduling, routing, accounting and distribution are all issues which are addressed in other fields of play and the lessons learned in more mature arenas will most likely ultimately apply to our game as well. We have enough problems of our own without ignoring the ones that have already been solved. Interoperability - The requirements of interoperability with other installations, existing systems and systems being designed is also high. It is my assumption that other installations have requirements that differ from ours and in some cases, possibly exceed ours. It is also my assumption that if we could ever "union" the requirements under a common model, subset implementations would be interesting and often interoperable. Reliability - Reliability is perhaps one of the greatest challenges to network printing. The nature of the work makes certain aspects of quality control human based and often very difficult. This leads to an assumption that similar reliability in submission, spooling, scheduling and delivery is appropriate. There are many things which can be done to minimize reliability and quality issues that are not. The requirement of reliability is an often undersold one in this world. Details of my environment... Thousands of users from different administrative, technical, geographic and even "cultural" domains use various services offered by the PAGES (Print And Graphics Express Station) system here at Los Alamos. They generate millions of images per month and millions of multi-image jobs per year to be recorded on various film and paper formats. We even offer photoplot services and are developing video and considering CD-Rom services. Operations runs 24 hours, 365 days. Many of these clients work from Suns, Macs, PCs, a myriad of Unix boxes and a moderate variety of proprietary and even homegrown systems. They have varying degrees of connectivity ranging from standalones with floppy drives through modems and appletalk through ethernet to FDDI and Gigabit special purpose networks. Other clients work directly on the "big iron". Connection Machines, Crays, IBMs, Workstation Clusters, or on remote machines at other labs or universities. All of these customers need access to our large volume resources as well as support for printing files on their own personal or departmental printers. Distribution of output is done via internal as well as external couriers, messengers and mail systems. Accounting for services is required. No overhead $$ is available except possibly for R&D into new services. Classified as well as "official use" data is processed. "large" special interest communities exist. Engineering, Administrative, Scientific, Facilities Mangagement, Artistic, and other groups drive requirements in different directions. Secretaries and Rocket Scientists have to work along side computer hackers. *** Enough for now. Any comments? Steve Smith Los Alamos National Laboratory sas@lanl.gov   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04491; 24 Jul 92 12:07 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04487; 24 Jul 92 12:07 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa20636; 24 Jul 92 12:07 EDT Received: by inet-gw-2.pa.dec.com; id AA19007; Fri, 24 Jul 92 09:07:16 -0700 Received: by nsl.pa.dec.com; id AA12034; Fri, 24 Jul 92 08:40:27 -0700 Received: by nsl.pa.dec.com; id AA12030; Fri, 24 Jul 92 08:40:26 -0700 Received: by inet-gw-2.pa.dec.com; id AA17394; Fri, 24 Jul 92 08:40:21 -0700 Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)id AA27706; Fri, 24 Jul 92 11:30:20 -0400 Received: from anvil.murkworks.com by murkworks.com (4.1/3.2.083191-MurkWorks)id AA03875; Fri, 24 Jul 92 11:07:37 EDT Message-Id: <9207241507.AA03875@murkworks.com> To: print-wg@pa.dec.com Subject: NPA spec, anyone have it? Date: Fri, 24 Jul 92 11:07:36 EDT From: Brad Clements Does anyone have the new NPA spec online for us to see? It'd probably be worthwhile seeing what the NPA proposes as `useful' device information. One could probably infer that manufacturers supporting NPA will probably stick with the design across all their future devices. Therefore we'll be supporting it sooner or later.   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04520; 24 Jul 92 12:09 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04516; 24 Jul 92 12:09 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa20697; 24 Jul 92 12:09 EDT Received: by inet-gw-2.pa.dec.com; id AA19126; Fri, 24 Jul 92 09:09:11 -0700 Received: by nsl.pa.dec.com; id AA12053; Fri, 24 Jul 92 08:43:40 -0700 Received: by nsl.pa.dec.com; id AA12049; Fri, 24 Jul 92 08:43:39 -0700 Received: by inet-gw-1.pa.dec.com; id AA06779; Fri, 24 Jul 92 08:43:15 -0700 Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)id AA27705; Fri, 24 Jul 92 11:30:17 -0400 Received: from anvil.murkworks.com by murkworks.com (4.1/3.2.083191-MurkWorks)id AA03867; Fri, 24 Jul 92 11:05:49 EDT Message-Id: <9207241505.AA03867@murkworks.com> To: Steve Smith Cc: print-wg@pa.dec.com Subject: Re: Requirements for a network printing environment (long?) In-Reply-To: Your message of "Thu, 23 Jul 92 13:12:33 EDT." <9207231912.AA07009@next-s.lanl.gov> Date: Fri, 24 Jul 92 11:05:49 EDT From: Brad Clements Steve, Your ideas sound great, do you have any kind of written proposal? One thing to keep in mind is that part of the original target for this group was (as I recall) taking into consideration so called resource-poor clients (aka PCs) and servers (aka Netports, etc). Any kind of design that we come up with should probably take into consideration components of this type. A so-called grand design, with a subset implementation now and full blown implementation later sounds nice in theory. I wonder how well it could be done in practice. How many projects go into the implementation phase, only to find that the design wasn't up to snuff. Is it possible that this type of approach to a printing protocol might put us into a position later which is similar to the LPR spec problem today? As mentioned previously on this list, the LPR protocol was designed for line printers, but a few extensions moved it into supporting other media. Today we find that the protocol isn't much good for either application because the way we address output devices today is different from when the spec was first designed. Could an extensible specification be written today (as you propose) which could stand up to new media types in the future, as well as new ways of using such media? Its not just the devices and the print information that needs to be addressed, but also the way they are used and accessed. -- Other IETF WGs have run into tar pits over similar design questions. If we attempt to design in everything from the start, the spec will be outdated before anyone can implement it. If we make some modules optional, implementations might not interoperate correctly unless a least common denominator is defined. Even then, if the LCD is too weak to be useful, the spec won't get far. If we define a spec that is extensible (that'd be nice), but don't clearly define how extensions are added (ie: that they should go through the same proposal process as the original spec), then we could run into a problem similar to the telnet environment option. That spec defined how certain client environment variables could be requested by the server, defined a few common variables that probably should be supported, and left it wide open for any new ones to be `defined'. A lot of good things have been attached to these environment variables, but quite a few duplicate and cloudy items have been attached as well. With no body governing the extension of this feature, its every-person for themself. In the end there will probably be many implementions of similar, but slightly different variables, and no one will be able to interoperate. -- So, for as much as I think the `big plan' sounds good, I'd like to see everyone keep the above comments in mind when proposing or designing a spec that will hopefully solve all our problems (and make you famous to boot). These are my comments, what are yours? -brad   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06713; 24 Jul 92 14:08 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06709; 24 Jul 92 14:08 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa25916; 24 Jul 92 14:08 EDT Received: by inet-gw-2.pa.dec.com; id AA26134; Fri, 24 Jul 92 11:07:54 -0700 Received: by nsl.pa.dec.com; id AA12976; Fri, 24 Jul 92 10:06:00 -0700 Received: by nsl.pa.dec.com; id AA12972; Fri, 24 Jul 92 10:05:59 -0700 Received: by inet-gw-2.pa.dec.com; id AA22365; Fri, 24 Jul 92 10:05:58 -0700 Received: from next-s.lanl.gov by p.lanl.gov (5.65/1.14)id AA19760; Fri, 24 Jul 92 11:05:54 -0600 Received: by next-s.lanl.gov (NeXT-1.0 (From Sendmail 5.52)/5.17)id AA07551; Fri, 24 Jul 92 10:59:59 MDT Date: Fri, 24 Jul 92 10:59:59 MDT From: Steve Smith Message-Id: <9207241659.AA07551@next-s.lanl.gov> Received: by NeXT Mailer (1.62) To: Brad Clements Subject: Re: Requirements for a network printing environment (long?) Cc: Steve Smith , print-wg@pa.dec.com Brad, Thanks for your comments, and especially the reality check on what happens with commitees, working groups and "grand designs". Part of my reason for casting my ideas upon the IETF waters is that in my own environment I have little interest in the details or interest only in the details. Management just wants it all to work up to an ill-defined and traveling spec. The worker bees just want it to do what they want it to do and to hell with everybody else. My implementers just want it to be "doable", "the design should only be as big as the resource to implement it". All very valid positions and points. The IETF print-wg clearly has put some miles on this effort and has found some of the pitfalls of standards and the like. I agree. I'm not sure I am looking for a place to spend more precious energy but I AM looking for a place to share ideas and develop synergistic relationships and the like. I am stuck on any formal proposals... I have a number of assigned ones on the table right now but the audiences are radically different than the IETF. Would the IETF print-wg want me to make a proposal to them? What would that entail? What would you want? What would that commit me to? What I am currently delivering includes: "Network Printing Strategy for ICN2" (a high-level design for printing within the context of our local network(s)), and "Network Output Strategies" (a high-level design for output of electronic information throughout the laboratory, including traditional graphic arts, library needs, facilities management and GIS map generation, et cetera). These are both targeted at specific management groups and are twisted to their needs. Attaching something intended for a more general audience (such as yourselves) or something generated under joint collaboration would be good for both of the above efforts. Anyone interested in this? Who all is active on this list and cares about these issues? Is everyone worrying only the spooler issues? Can we let go of the spooler concept and embrace a more serious "print server" model? - Steve   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07814; 24 Jul 92 15:07 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07810; 24 Jul 92 15:07 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa29164; 24 Jul 92 15:07 EDT Received: by inet-gw-2.pa.dec.com; id AA29634; Fri, 24 Jul 92 12:07:40 -0700 Received: by nsl.pa.dec.com; id AA13661; Fri, 24 Jul 92 11:06:44 -0700 Received: by nsl.pa.dec.com; id AA13657; Fri, 24 Jul 92 11:06:43 -0700 Received: by inet-gw-1.pa.dec.com; id AA17190; Fri, 24 Jul 92 11:06:40 -0700 Received: by spot.CC.Lehigh.EDU id AA18454 (5.65c/IDA-1.4.4 for print-wg@Pa.dec.com); Fri, 24 Jul 1992 14:06:29 -0400 From: lumm@spot.cc.lehigh.edu Message-Id: <199207241806.AA18454@spot.CC.Lehigh.EDU> Subject: Re: Requirements for a network printing environment (long?) To: Brad Clements Date: Fri, 24 Jul 92 14:06:28 EDT Cc: print-wg@pa.dec.com In-Reply-To: <9207241505.AA03867@murkworks.com>; from "Brad Clements" at Jul 24, 92 11:05 am X-Mailer: ELM [version 2.3 PL11] > > So, for as much as I think the `big plan' sounds good, I'd like to see everyone > keep the above comments in mind when proposing or designing a spec that will > hopefully solve all our problems (and make you famous to boot). > > These are my comments, what are yours? > > -brad > Brad, We here at Lehigh also have a simple "SMTP like protocol" for printing that we have been using for the years. Interestingly, it was initially viewed as a interim thing to hold us over until a standard was deleveloped, but... Here's a blurb on it, we have versions for Unix, VMS, VM, DOS, and NOS/VE. Available from ftp.Lehigh.EDU. Simple, but expandable. Perhaps not the best solution for a complete standard, but it is simple enough for small machines. mark ----- SQTP is used at Lehigh University for transfering I/O files between heterogeneous operating systems. SQTP consists of servers for NOS/VE, VM, VMS and Unix, and clients for these operating systems as well. The U*X clients are externalized as commands OP and OQ for printing output files and viewing the output queues, and IP and IQ for submitting input jobs to remote machines and getting the output back and viewing the input queue. To install SQTP/Unix, read the makefile. -- ----------------------------------------------------------------------------- Mark Miller Network Analyst lumm@Lehigh.EDU Lehigh University Computing Center lumm@spot.CC.Lehigh.EDU Bethlehem, PA 18015 -----------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07854; 24 Jul 92 15:09 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07850; 24 Jul 92 15:09 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa29241; 24 Jul 92 15:09 EDT Received: by inet-gw-2.pa.dec.com; id AA29714; Fri, 24 Jul 92 12:09:00 -0700 Received: by nsl.pa.dec.com; id AA14765; Fri, 24 Jul 92 11:56:07 -0700 Received: by nsl.pa.dec.com; id AA14761; Fri, 24 Jul 92 11:56:04 -0700 Received: by inet-gw-2.pa.dec.com; id AA28954; Fri, 24 Jul 92 11:56:02 -0700 Received: by emulex.emulex.com id AA06618 (5.64+/IDA-1.3.4 for print-wg@Pa.dec.com); Fri, 24 Jul 92 11:57:59 -0700 Date: Fri, 24 Jul 92 11:57:59 -0700 From: Charles Bazaar Message-Id: <9207241857.AA06618@emulex.emulex.com> To: print-wg@pa.dec.com Subject: Network Printing Requirements Resourse pour clients are important to us, but just as important is status information. Most current spooling implementations (lpr/lpd for instance) do not take into consideration status information available from the physical device. Much of this is probably due to the inability of the parallel interface to provide returned information. With new bi-directional parallel interface proposals pending, a new lpr/lpd proposal should have the capability to accept and/or query for status info. Of course there remains questions of how this information would be made available to applications (spoolers, word processing pgms, etc.) Charles Bazaar bazaar@emulex.com   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08924; 24 Jul 92 16:07 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08911; 24 Jul 92 16:07 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa02214; 24 Jul 92 16:07 EDT Received: by inet-gw-2.pa.dec.com; id AA03359; Fri, 24 Jul 92 13:07:30 -0700 Received: by nsl.pa.dec.com; id AA16248; Fri, 24 Jul 92 12:33:41 -0700 Received: by nsl.pa.dec.com; id AA16244; Fri, 24 Jul 92 12:33:40 -0700 Received: by inet-gw-1.pa.dec.com; id AA23362; Fri, 24 Jul 92 12:33:34 -0700 Message-Id: <9207241933.AA23362@inet-gw-1.pa.dec.com> Date: Fri, 24 Jul 92 15:29:45 EDT From: Brad Clements To: Charles Bazaar Cc: print-wg@pa.dec.com Subject: Re: Network Printing Requirements Is your Tri-Protocol release 3.0 unit going to do anything with the NPA spec? perhaps an SNMP queriable kinda thing? -- What would a general client want to know about the physical device? I can see a management station wanting to query it, but the dumb PC probably not.. | Brad Clements, CCP bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab09213; 24 Jul 92 16:09 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09205; 24 Jul 92 16:09 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa02312; 24 Jul 92 16:09 EDT Received: by inet-gw-2.pa.dec.com; id AA03489; Fri, 24 Jul 92 13:09:23 -0700 Received: by nsl.pa.dec.com; id AA15878; Fri, 24 Jul 92 12:07:41 -0700 Received: by nsl.pa.dec.com; id AA15874; Fri, 24 Jul 92 12:07:40 -0700 Received: by inet-gw-2.pa.dec.com; id AA29627; Fri, 24 Jul 92 12:07:38 -0700 Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)id AA21190; Fri, 24 Jul 92 14:25:06 -0400 Received: from anvil.murkworks.com by murkworks.com (4.1/3.2.083191-MurkWorks)id AA04141; Fri, 24 Jul 92 14:15:23 EDT Message-Id: <9207241815.AA04141@murkworks.com> To: Steve Smith Cc: print-wg@pa.dec.com Subject: Re: Requirements for a network printing environment In-Reply-To: Your message of "Fri, 24 Jul 92 10:59:59 EDT." <9207241659.AA07551@next-s.lanl.gov> Date: Fri, 24 Jul 92 14:15:21 EDT From: Brad Clements I can't speak for the WG, but my understanding is that this is an open forum and all input is welcome. I for one would like to see your "network printing for ICN2" document. I'm not sure how the other one you mentioned would relate to the purposes of this group, but you'ld know better than me. Seems to me the objective of this group is to produce a recommended network based printing protocol (lan, man, wan?) that satisfies the basic requirements of all interested parties. I suppose the most basic requirement (and the least interesting) is: node A has output for printer B, how does it get there? -- In the LAN environment (Novell) some interesting products have come out to solve the issue of pairing print data requirements with available resources (ie: sending documents of type A to printers of type A making sure that fonts B and C are also sent, etc). Some of these products handle all of this stuff transparently to the user (nice). Of course thats not hard in a homogenous networking environment. Or at least, not as hard as doing the same for a mixed bag of platforms and systems. -- I say, what the heck, shoot for the sky in the original proposal. A reality check into the technical and financial requirements of development produce a first-filtered design. Followed by a second reality check of `what does the market really want' gets you to round two. The last step is `what do the vendors really want to do'? (ie: what will sell). I'm not saying that proposals from this group should be governed by vendors. But I imagine that vendors are the ones most likely to have the resources required to make any such protocol `wide-spread'. Perhaps thats a naive view on my part. Any protocols from this group that are 1) useful, 2) actually work, 3) easy to administer, and 4) have freely available reference implementations will probably take off like other recent networking tools (archie, gopher, etc). -- I do believe that this group has already acknowledged the need to move beyond the spooler/no spooler issue. However after that point, the group seemed to just wither on the vine. I'd like to know who is in this group, and who wants to keep going. Heck, if there are only three or four of us, then this group is effectively defunct. Might as well run off and do an SMP vis SNMP coup! -Brad   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10507; 24 Jul 92 17:07 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10503; 24 Jul 92 17:07 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa05448; 24 Jul 92 17:07 EDT Received: by inet-gw-2.pa.dec.com; id AA06796; Fri, 24 Jul 92 14:07:28 -0700 Received: by nsl.pa.dec.com; id AA17187; Fri, 24 Jul 92 13:25:25 -0700 Received: by nsl.pa.dec.com; id AA17183; Fri, 24 Jul 92 13:25:24 -0700 Received: by inet-gw-2.pa.dec.com; id AA04389; Fri, 24 Jul 92 13:25:21 -0700 Received: from next-s.lanl.gov by p.lanl.gov (5.65/1.14)id AA25651; Fri, 24 Jul 92 14:25:19 -0600 Received: by next-s.lanl.gov (NeXT-1.0 (From Sendmail 5.52)/5.17)id AA07664; Fri, 24 Jul 92 14:19:24 MDT Date: Fri, 24 Jul 92 14:19:24 MDT From: Steve Smith Message-Id: <9207242019.AA07664@next-s.lanl.gov> Received: by NeXT Mailer (1.62) To: print-wg@pa.dec.com Subject: Remote device access VS service provision Gang, From some of the comments I have received, I have the general impression that many of us approach printing (rendering images to physical media) as access to a printing device and network printing as remote, spooled access to a printing device. I view it as provision of a service and that the features of existing device represent, in their composition, an approximation of the characteristics of the service. A print service is more than access to a printer, a network print service is more than spooled access to a printer. Certainly even the two above are hard enough but adding full-service characteristics to the model are important in many applications. How many of "us" are interested in "print services" rather than "printer access" ? I believe that presentation of a "print service" to clients as "remote access" to a printer is powerful as it draws on their existing understanding. However, implementations that restrict the available solutions to "access to a printer" limit the service available. Thanks for all the input so far... I'll be looking forward to more. - Steve   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01267; 25 Jul 92 13:08 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01263; 25 Jul 92 13:08 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa10354; 25 Jul 92 13:08 EDT Received: by inet-gw-2.pa.dec.com; id AA11209; Sat, 25 Jul 92 10:08:14 -0700 Received: by nsl.pa.dec.com; id AA15125; Sat, 25 Jul 92 09:34:55 -0700 Received: by nsl.pa.dec.com; id AA15121; Sat, 25 Jul 92 09:34:54 -0700 Received: by inet-gw-1.pa.dec.com; id AA13726; Sat, 25 Jul 92 09:34:51 -0700 Message-Id: <9207251634.AA13726@inet-gw-1.pa.dec.com> Received: by UMDD.UMD.EDU id 3370 ; 25 Jul 92 12:35:33 EDT Received: by UMDD (Mailer R2.08 PTF008) id 3370; Sat, 25 Jul 92 12:35:31 EDT Date: Sat, 25 Jul 92 11:59:15 EDT From: Bruce Crabill Subject: Remote device access VS service provision In-Reply-To: Message received on Fri, 24 Jul 92 17:22:55 EDT To: print-wg@pa.dec.com I tend to view it to be more than just remote access to a printer. To me, I'm more interested in standardizing what is basically a network spooling system. The user submits print requests to a server using this protocol. The server may or may not have direct communications with the printer (via a serial line to a Laserwriter, PAP to a LPS/40, channel attachment to a IBM 3800, etc). If not, then the server would use the same protocol to forward the job to the server that does (or at least closer to the server that does). The actual protocol to the device is a seperate issue and maybe a single protocol is not sufficient. The Dec PAP protocol works nicely for their LPS/40 class printers, but may not be suitable for other printers. At the University of Maryland, we have a protocol called NPP (and an offical TCP port by the same name) that we have been using to address the submittal to the spool system portion. It is a SMTP like, easy to implement protocol. Our current protocol spec needs a bit of cleaning up, but I'll append it so you can get an idea of the protocol. Bruce ------------------------------------------------------------------------- Network Printing Protocol (NPP) Protocol Definition NPP is a protocol designed to enable the queuing [spooling] of files to network attached devices such as printers or other output devices. The protocol follows the model used by SMTP and FTP. It is designed to be easy to implement on a variety of systems with a minimum of system dependencies. In the examples given below, lines that are prefixed with ">" are lines that are sent from a client to a server and the lines prefixed with "<" are responses from the server to the client. NPP uses port 92 for the server. Protocol: The queuing protocol consists of a simple command/response client- server model. The client issues commands to the server, and the server supplies responses. The commands and responses consist of up to 256 ASCII characters (not counting the end-of-line carriage return/linefeed pair) conforming to the Net-ASCII standard (e.g. carriage returns are followed by a linefeed). The data portion of commands such as Write and Set is preceded by a count and the data may not necessarily consist of Net-ASCII characters, thus care must be taken to insure the data portion of a command is not converted into Net-ASCII form unless specified by the mode attribute (see the Set command below). Commands: A command consists of a command name (which can be no longer than 64 characters), followed by optional command arguments seperated by one or more spaces, followed by the end-of-line carriage return/linefeed pair. This end-of-line sequence will be indicated as "" in the examples included in this document. In some cases, there is a variable amount of data appended to the command after the end-of-line sequence. In this case, one of the command arguments will contain the number of octets of data appended. An end-of-line sequence does not follow data. With the exception of the host and userid portions of the HELLO command, case is not significant in the command name or the arguments associated with it. Protocol Replies: A reply consists of a three digit decimal response code and an optional text message describing the reply followed by the end-of-line sequence. When the option text portion is present, then it will be seperated from the response code by at least one space. These replies are modeled after the FTP reply format. In some cases, indicated by messages of the x1x class, the reply consists of parsable data which must be understood by the client program. [continuations?] Request Success: The first digit of the response code indicates the success of the requested command. The following values are defined: 1xx Positive Preliminary Reply The command is in the process of completing successfully and the client should await further replies. 2xx Positive Completion Reply The command has completed successfully. 3xx Positive Intermediate Reply The command was successfully, but further commands are necessary for final completion of the command. For example, the WRITE command will return a 3xx message upon successful completion, thus indicating a CLOSE command is necessary before the object can be guaranteed to be written to the queuing system. 4xx Transient Negative Completion Reply An error was encountered while processing the command, and the queuing system has therefore rejected the command. The command may be reissued with different parameters or after other commands and may work. 5xx Permanent Negative Completion Reply The queuing system detected an error from which it was unable to recover. This reply indicates a fatal error and the server will follow this reply by closing the connection. Functional Group: The second digit of the response code indicates which part of the system is replying with the response code. Special care should be taken with the class x1x messages, as its data is intended to be parsable by the client program. x0x Syntax The command is not known or has an invalid argument. x1x Information Response to a GET command or other status type information. x2x Connections Information about the establishment and termination of the TCP connection to the server. x3x Authentication Messages dealing with the authentication information provided on the HELLO command. May also be received on the OPEN command if the server has restricted queues. x4x System The response is related to server's spooling system (with the exception of data transfer messages). x5x File System Information having to do with the transfer of data from the client into the server's spooling system. The third digit is used to provide further granularity among error messages of the same response and subsystem type, but has no significance otherwise. In implementing code to check the response code, only the first digit needs to be checked, the second and third digits are provided to help further classify a response, but the first digit will indicate the success of a command. Initial Greeting: When a client initially connects to the server, the server will send the client an initial greeting message. This message has the form: 220 The 220 portion is required, but the greeting text format is at the server's discretion. It is recommended that it identify the server type and the name of the host that the server is running on. If supplied, it must be seperated from the 220 response code by one or more spaces. Examples: < 220 NPP Server ready [haven.umd.edu] < 220 You have reached the NPP server at UMDD.UMD.EDU. Command Descriptions: Hello Initiate a session HELLO [] Arguments: Version Id Version of the protocol Host Id Host who is enqueuing/has enqueued an object User Id User who is enqueuing/has enqueued an object Auth Type Type of authentication method Auth Data Length Length of data used in authentication Auth Data Data used in authentication Description: This command initiates a queuing session. A queuing session consists of all commands up to and including the QUIT command. The version identifier is an integer value indicating the version of the protocol which the client is using. The only currently acceptable value is "1". The host identifier is the fully qualified domain name of the host who is enqueuing or has enqueued an object, which may not necessarily be the name of the host which initiated the session. The user identifier is the userid of the user who is enqueuing or has enqueued an object. As with the host identifier, the user identifier is not necessarily the user who has initiated the queuing session. The host and userid fields of the HELLO command are case sensitive, as they are used in validation which is server dependent. The authentication type indicates which method of authentication is to be used and can be one of the following values: 0 No authentication 1 UNIX-DES 2 Kerberos 3 Plain text When no authentication is specified, the client is restricted in some commands. The authentication length is an integer field indicating the length of the authentication data immediately following the end-of-line sequence. [we realize that the authentication mechanism needs some work, we may need some specific authentication commands] Examples: > Hello 1 trout.ab.umd.edu fred 1 8nK894n90 < 230 Welcome, user authenticated > Hello 1 umdd.umd.edu test 0 0 < 231 Welcome, some restrictions apply > Hello 1 BRUCE-BIG-PC.UMD.EDU BRUCE 3 5XYZZY < 232 User valid, continue Open Open a queue OPEN Arguments: Queue Queue to enqueue object to Description: The OPEN command will open the specified queue for writing. This command will return an informational message which is to be parsed by the client program in the following format: 21x The Qid return parameter is the identifier to be used hereafter to reference the object which is in the process of being enqueued. Format of Qids consists of up to 128 ASCII printable characters (from the subset of X'21' to X'7E'). Care should be taken on the part of the server to insure global uniqueness, perhaps by including the server host and enqueuing userid along with a time stamp, as the Qid must be globally unique throughout the entire queuing system. The buffer size value which is returned indicates the largest amount of data the server is willing to receive on a write command. If the buffer size return value is 0, the client may send any amount of data on a single WRITE command. [we should explicitly define how to make the Qid unique] Examples: > Open lw < 210 fred@trout.ab.umd.edu.97a83b33 0 > Open 3800 < 219 BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397 4096 Write Write data to a queue WRITE [] Arguments: Count Number of bytes to write (carriage return/linefeed) Data Count bytes of data Description: The WRITE command will write a specified amount of data to the queue which was opened on the previously specified OPEN command. The count argument indicates the amount of data immediately following the end-of-line sequence and should in all cases be smaller than or equal to the buffer size the server supplied on the response to the OPEN command. The data transfer mode defaults to Net-ASCII but may be set to another value using the SET command (see below) prior to the issuance of the WRITE command. The normal response from the WRITE command is a 3xx message indicating further action need be taken prior to successful completion of the command. In this case, the queuing system is expecting a CLOSE command to successfully complete the transfer. In the event of a connection failure or the client issues a QUIT command without giving the CLOSE command, the queue will be implicitly closed and a REMOVE command will be issued on the Qid generated by the previous OPEN command. Example: > Write 101234567890 < 350 Data Written Segue Seperate logical files SEGUE Arguments: None Description: The SEGUE command is used to mark the logical end-of-file of the current file. This is useful where several files are being printed in a single request. [this needs to be documented more completely...] [and perhaps a better command name...] Example: > Segue < 341 Logical EOF marked Close Close a queue CLOSE Arguments: None Description: The CLOSE command terminates a data transfer. After the close, the object enqueued will be held until either explicitly released via the RELEASE command or implicitly released with the QUIT command. The CLOSE command will return a 25x class message indicating the data transfer completed successfully and the data previously transferred via WRITE commands has been accepted by the queuing system. Example: > Close < 250 Closed Quit Terminate a session QUIT Arguments: None Description: The QUIT command will terminate a queuing session, freeing up any resources associated with the session. If a Qid is open when the QUIT command is received, the Qid will be implicitly closed and removed and the data will be lost. At the issuance of a QUIT command, any closed Qids which haven't been explicitly released will be implicitly released. Example: > Quit < 220 So long, see you next time Remove Remove an item from a queue REMOVE Arguments: Qid Qid of object to remove from the queuing system Description: The REMOVE command removes an object from the queuing system. An object may only be removed after it has been closed and before the object reaches the actual device(s) that implement the queue the object was enqueued to. If the client initiated the session with no authentication, REMOVEs can only be applied to objects enqueued during the current session. Example: > Remove fred@trout.ab.umd.edu.97a83b33 < 240 Object destroyed. Release Release an item to the queuing system RELEASE Arguments: Qid Qid of object to release to queuing system Description: The RELEASE command will allow an object to be released to the queuing system for processing. Note that releasing an object does not insure immediate printing, since many jobs may be enqueued before the object just released or the object may have a delay applied to it (see SET below). If the client initiated the session with no authentication, a release can only be applied to objects enqueued during the current session. Example: > Release fred@trout.ab.umd.edu.97a83b33 < 240 Released Set Set an attribute for an item SET [] Arguments: Qid Qid of object to set attribute on Attribute Attribute to set Count Number of octets in attribute value Value Value of attribute to be applied to object Description: The SET command applies a specified value to a specified attribute. An attribute consists of a up to 64 Net-ASCII printable characters not including space characters. The count parameter indicates the length in octets of the attribute value which immediately follows the end-of-line sequence. The attribute value may not necessarily be Net-ASCII characters, so care must be taken not to apply Net-ASCII transformations on the attribute value. The following attributes have been defined: [the following list may need additions or deletions] BANNER The user identification value to be output on the header page. The default is to use "@" using the information supplied on the HELLO command. COPIES The number of copies of the given file that are to be output. The default is 1. FORMAT TEXT or POSTSCRIPT The structure of the data in the given file. TEXT indicates normal text with any line formatting characters included in the text. POSTSCRIPT indicates that the file contains a PostScript program that should be executed by the output device. The default is TEXT. FORMFEED TRUE or FALSE If this is set to TRUE, then the device driver (if it supports such a feature) should insert a FF character between copies of an output file. The default is TRUE. FORMS
The name of the forms to be used to output the file. The default is "white". INDENT TRUE or FALSE If this is set to TRUE, then the device driver (if it supports such a feature) may indent the output. The default is TRUE. MAIL TRUE or FALSE If this is set to TRUE, then when the file is processed by the requested network device, the submitter is to be sent a mail message indicating this. The default is FALSE. MAILID @. The mail address to be used for advisories (errors or if the MAIL attribute is set to TRUE). The default is to use the information supplied on the HELLO command. MODE NETASCII, EBCDIC, or BINARY The representation of the data in the given file. The default is NETASCII. PRIORITY A value in the range 0 to 127 that specifies the priority of the request. 0 is the highest priority (will be printed first) and 127 is the lowest. The default is 64. START The given file should be held until the indicated time. Time is given as seconds since midnight January 1, 1970. The default is to not hold the file. TITLE The title of the file to be output. This appears on the header page. XARG <value> An extended argument that is given to the device driver. These extended arguments are device driver specific. More than one XARG attribute may be set. Examples: > Set fred@trout.ab.umd.edu.97a83b33 delay 2<EOL>30 < 240 Attribute set<EOL> > Set BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397 title 34<EOL> > This is the title of the print out < 241 Attribute set<EOL> Get Get an attribute for an item GET <Qid> <Attribute><EOL> Arguments: Qid Qid of object to get attribute from Attribute Attribute name to get value of Description: The GET command obtains the value of the specified attribute for the object denoted by the specified Qid. The GET command will return a parsable response in the following format: 21x <length><EOL><value> The length return parameter indicates the length of the attribute value which immediately follows the end-of-line sequence. The value parameter consists of exactly length bytes of non-Net-ASCIIized data which constitutes the value of the attribute requested. Examples: > Get fred@trout.ab.umd.edu.97a83b33 delay<EOL> < 211 2<EOL>30 > Get BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397 TITLE<EOL> < 212 34<EOL>This is the title of the print out List LIST <Queue><EOL> Arguments: Queue Which queue to search for objects Description: The LIST command obtains a list of all Qids associated with the userid specified on the HELLO command which are currently in the queuing system. Each Qid will be returned in a seperate 11x type response with the end of list being marked with a 24x response. If there are no Qids associated with the user, then just the 24x response will be returned. Examples: > List lw<EOL> < 110 fred@trout.ab.umd.edu.97a83b33<EOL> < 241 List complete<EOL> > List 3800<EOL> < 110 BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397<EOL> < 110 BRUCE@BRUCE-BIG-PC.UMD.EDU.F81C9E319B7CFFE1<EOL> < 241 List complete<EOL> > List lps40<EOL> < 242 Nothing found<EOL> Examples: The following is an example of a complete transaction. [Open TCP connection to port 92] < 220 NPP Server ready [haven.umd.edu]<EOL> > HELLO 1 UMDD.UMD.EDU BRUCE 0 0<EOL> < 230 Welcome, some restrictions apply<EOL> > OPEN lps40<EOL> < 210 BRUCE@UMDD.UMD.EDU.25d33b16.6e 65536<EOL> > SET BRUCE@UMDD.UMD.EDU.25d33b16.6e TITLE 13<EOL>T1212 LISTING < 242 Attribute set<EOL> > WRITE 15561<EOL>(15561 bytes of data) < 350 Data written<EOL> > CLOSE<EOL> < 250 Closed<EOL> > RELEASE BRUCE@UMDD.UMD.EDU.25d33b16.6e<EOL> < 240 QID Released<EOL> > QUIT<EOL> < 220 Adios<EOL> [Close TCP connection]   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10643; 30 Jul 92 20:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10639; 30 Jul 92 20:03 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa11127; 30 Jul 92 20:04 EDT Received: by inet-gw-2.pa.dec.com; id AA26740; Thu, 30 Jul 92 17:04:05 -0700 Received: by nsl.pa.dec.com; id AA16228; Thu, 30 Jul 92 16:42:14 -0700 Received: by nsl.pa.dec.com; id AA16224; Thu, 30 Jul 92 16:42:12 -0700 Received: by inet-gw-1.pa.dec.com; id AA05392; Thu, 30 Jul 92 16:42:09 -0700 Message-Id: <9207302342.AA05392@inet-gw-1.pa.dec.com> Date: Thu, 30 Jul 92 19:38:48 EDT From: Brad Clements <bkc@omnigate.clarkson.edu> To: print-wg@pa.dec.com Subject: NPA spec now available via anonymous FTP (and email) Thanks to Don at Lexmark, the NPA spec is now available via anonymous ftp from barnacle.erc.clarkson.edu (128.153.28.12) pub/ietf/print-wg/npa-l1rd.exe This is a self-extracting DOS executable. Download to a PC in binary mode and execute it to produce PostScript text for your PS printer. The .exe file is a little over 1 megabyte in size. -- For email, send a message to archive-server@sun.soe.clarkson.edu send ietf/print-wg/npa-l1rd.exe for packing and encoding choices, send a help message instead. -- The following comment is from Don, and I think its important for others to read this before getting the spec. My objective in introducing the spec to this group is to use it as a sample of the types of management/control information that a printing protocol may want to deal with in the future. I haven't seen the spec yet myself, so I'm shooting `from the hip'. ---- Date: Thu, 30 Jul 92 17:24:52 EST From: "Don Wright (606)232-4808 " <don@lexmark.com> To: bkc@omnigate.clarkson.edu Subject: ftp drop off for NPA You and everyone else should understand that the purpose of the NPA document is provide a link independent protocol for hosts to talk to printers. It must run on a parallel port, RS-232, Ethernet, etc. and should not be tied to a high level component in the protocol stack; i.e. it could be encapsulated in the NetBios, IPX/SPX, TCP, etc. In addition it is designed for ease of implementation in a resource poor device like a printer. That is why data is generally bit/byte encoded; parsing English or other human languages is too complex for a device like a printer. Have fun! +-----------------------------------------------------------------------+ | Don Wright Lexmark International | | Manager, Attachment Products Dept C18L/035-3 | | Phone: 606-232-4808 740 New Circle Rd | | Fax: 606-232-6740 Lexington, KY 40511 | +-----------------------------------------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10981; 30 Jul 92 23:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10977; 30 Jul 92 23:03 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa15579; 30 Jul 92 23:03 EDT Received: by inet-gw-2.pa.dec.com; id AA03756; Thu, 30 Jul 92 20:03:46 -0700 Received: by nsl.pa.dec.com; id AA17650; Thu, 30 Jul 92 19:13:13 -0700 Received: by nsl.pa.dec.com; id AA17646; Thu, 30 Jul 92 19:13:10 -0700 Received: by inet-gw-1.pa.dec.com; id AA11614; Thu, 30 Jul 92 19:13:05 -0700 Message-Id: <9207310213.AA11614@inet-gw-1.pa.dec.com> Date: Thu, 30 Jul 92 22:09:35 EDT From: Brad Clements <bkc@omnigate.clarkson.edu> To: print-wg@pa.dec.com Cc: don@lexmark.com Subject: NPA.PS has problems, don't get it yet The NPA spec PS source seems to be corrupted. It gets to page 8-18 and dies. Hand editing the source allows for printing to restart at page 8-23. Don, can you check your copy? In the meantime, be aware that the file expands to a 3.3 Megabyte PS file which takes more than 50 minutes to print on an HP IIISi. | Brad Clements, CCP bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07226; 14 Aug 92 17:01 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07222; 14 Aug 92 17:01 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa19218; 14 Aug 92 17:02 EDT Received: by inet-gw-2.pa.dec.com; id AA18291; Fri, 14 Aug 92 14:02:04 -0700 Received: by nsl.pa.dec.com; id AA19201; Fri, 14 Aug 92 13:41:17 -0700 Received: by nsl.pa.dec.com; id AA19197; Fri, 14 Aug 92 13:41:16 -0700 Received: by inet-gw-1.pa.dec.com; id AA06050; Fri, 14 Aug 92 13:41:02 -0700 Message-Id: <9208142041.AA06050@inet-gw-1.pa.dec.com> Date: Fri, 14 Aug 92 16:35:18 EDT From: Brad Clements <bkc@omnigate.clarkson.edu> To: powers@regent.enet.dec.com Cc: print-wg@pa.dec.com Subject: Re: NPA.PS has problems, don't get it yet Hmm, yes I think so. The .exe file appears to be ok, the .ps.Z file appears to be bad. Just get: barnacle.erc.clarkson.edu:/pub/ietf/print-wg/npa-l1rd.exe | Brad Clements, CCP bkc@omnigate.clarkson.edu | Sr. Network Engineer Clarkson University (315)268-2292   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08762; 14 Aug 92 20:00 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08758; 14 Aug 92 20:00 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa22947; 14 Aug 92 20:01 EDT Received: by inet-gw-2.pa.dec.com; id AA28050; Fri, 14 Aug 92 17:01:37 -0700 Received: by nsl.pa.dec.com; id AA21424; Fri, 14 Aug 92 16:42:48 -0700 Received: by nsl.pa.dec.com; id AA21420; Fri, 14 Aug 92 16:42:47 -0700 Received: by inet-gw-1.pa.dec.com; id AA15395; Fri, 14 Aug 92 16:42:46 -0700 Message-Id: <9208142342.AA15395@inet-gw-1.pa.dec.com> Received: by UMDD.UMD.EDU id 2337 ; 14 Aug 92 19:43:50 EDT Received: by UMDD (Mailer R2.08 PTF008) id 2337; Fri, 14 Aug 92 19:43:49 EDT Date: Fri, 14 Aug 92 19:33:22 EDT From: Bruce Crabill <BRUCE@umdd.umd.edu> Subject: Re: NPA.PS has problems, don't get it yet In-Reply-To: Message received on Fri, 14 Aug 92 17:06:30 EDT To: print-wg@pa.dec.com I was able to get a NPA.PS out of the NPA.EXE. Of course, owning a Mac made the exercise a bit of fun (but thats what they invented SoftPC for...). However, I wasn't real happy when it took 2 hours on a LPS40 to print. Reminds me why I'm not a big fan of PostScript RFCs. The brief scan I did of it, looks like it might be a good host to printer protocol, but I would like to see something like our NPP for the user to spooler protocol. I did find it humorous that they said that they didn't use something that required parsing commands, because printers are too simple to be able to do that but then goes on to specify a 200 some page protocol spec with flags a fields for everything in the world that somebody could thing of. By the way, who or what is the driving force behind this protocol? Bruce   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09112; 14 Aug 92 21:00 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09108; 14 Aug 92 21:00 EDT Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa23841; 14 Aug 92 21:01 EDT Received: by inet-gw-2.pa.dec.com; id AA01078; Fri, 14 Aug 92 18:01:45 -0700 Received: by nsl.pa.dec.com; id AA21986; Fri, 14 Aug 92 17:18:52 -0700 Received: by nsl.pa.dec.com; id AA21982; Fri, 14 Aug 92 17:18:52 -0700 Received: by inet-gw-1.pa.dec.com; id AA17129; Fri, 14 Aug 92 17:18:49 -0700 Message-Id: <9208150018.AA17129@inet-gw-1.pa.dec.com> Date: Fri, 14 Aug 92 20:13:11 EDT From: Brad Clements <bkc@omnigate.clarkson.edu> To: Bruce Crabill <BRUCE@umdd.umd.edu> Cc: print-wg@pa.dec.com Subject: Re: NPA.PS has problems, don't get it yet The NPA spec does take a long time to print, mostly due to a fancy logo printed at the top of every page. Now, funny thing is that they send the bitmap for the logo on every page. A spec put together by printer manufacturers... geesh, you'ld figure that they'd know PS enough to send the bitmap only once and call it as a proc after that. But, what the hey, its obviously the fault of the word processer they used (feh!, they didn't use TeX). -- Enough tongue-in-cheek. The spec was put together by printer manufacturers who've been taking a beating by the software folks for having ancient technology that doesn't talk. Well this spec is pretty all-encompasing. Does anyone know when any manufacturer will have out an NPA complient printer? -- My interest in the spec was to see the type of management information that `they' thought would be interesting. I'm not proposing the NPA spec for this group, neither in a client-to-spooler protocol nor in the spooler-to-device protocol. My point is that neither could be defined without a good grasp of the kind of capabilities that users want (which is presumably gleaned from what the manufacturers are willing to give). One might say that we need three protocols client to spooler spooler to device management agent to device/spooler Now my preference would be to have only one protocol that handles all three of these conditions. This way those applications in which the client must speak directly to the device could also be handled. Perhaps the gravity of NPA will will `force' subsequent specs to follow their lead. I suppose that depends on the market... | Brad Clements, CCP bkc@omnigate.clarkson.edu | Sr. Network Engineer Clarkson University (315)268-2292