CURRENT_MEETING_REPORT_ Reported by Glenn Trewitt/DEC NPP Minutes Agenda o ``Wire Protocol'' o RFC-1179 -- Line Printer Daemon Protocol o Network Printing Working Group Charter o Printer Access Protocol Proposal Two items were added: o Palladium o ``Son of LPR'' services ``Wire Protocol'' Glenn Trewitt advised the Working Group of the decision of the Telnet Working Group on the Wire Protocol, as described in the Agenda. The purpose of the Wire Protocol was to provide a standard mechanism for establishing a TCP connection to one of many physical ports on a host, e.g., a line on a terminal server. This connection should be capable of being 8-bit transparent. In Vancouver, the Working Group agreed that this ``protocol'' should be taken to the Telnet Working Group for further action. Bill Westfield agreed to do this. The result was somewhat surprising. The general consensus was that most of the terminal server vendors already provide a mechanism for doing this (generally by letting the user connect to a particular TCP port in order to get to a particular line or rotary with specified characteristics. The only advantage gained by defining a protocol to select the line and its characteristics would be to provide a standard protocol-function->line mapping. This was not viewed as providing a significant ``win'' over the existing implementations, which work fine, once you figure out the right TCP port number. To quote Bill: ``You ought to specify that the endpoint needs to be able to talk to an arbitrary tcp host/port, using the `stream' mode that most terminal server vendors now supply.'' 1 Trewitt feels this is an implementation issue (making lpd have the right functionality for connecting to printers) rather than a protocol issue (defining a protocol to do something that is currently not do-able or not standardized). RFC-1179 -- Line Printer Daemon Protocol RFC 1179 has been issued as ``informational'', and there was some question about the actual purpose of the RFC -- if we are specifying some changes to the de-facto protocol, it really needs to be in the standards track. If the intent is truly informational, it must only specify things that exist in common implementations. (This was agreed to mean ``the BSD lpd server''.) The major issue that was discussed was the order of data and control files - existing (big-machine) implementations take the data files first and send the control file last. ``Small-machine'' implementations typically can't spool the data files to wait and see what the control file says to do with it. As a result, these implementations must print the data file as best they can, without the help of any information that might be contained in the control file. A secondary (but still important) issue is that many small systems can't predict in advance, the size of the files to be printed (other than by storing them first, which they can't do). The existing RFC attempts to address these issues by changing the protocol slightly. The consensus was that, even though these were extremely desirable modifications, we couldn't change the protocol and still issue an informational RFC. There wasn't much support for the notion of pushing these modifications through the standards process, because there is so much old, ``free'' BSD code out there that won't get changed. It was suggested that anybody who wants to get these issues dealt with should go to the source, Berkeley, and hand them source code for a backward-compatible lpd that has these problems fixed, and get it incorporated into 4.4 BSD. As far as errors in the RFC, there was discussion about some of the things that it leaves unsaid. In particular, the BSD implementation of lpd is very picky about the order in which various commands are given. This makes it very difficult to implement a client, even if you have a complete, correct specification of the commands and their arguments (as in the RFC). The following are action items: 2 o Edit the RFC to remove the upgrades. o Add a section that discusses the order dependencies of the commands. Network Printing Working Group Charter We agreed that the Chair should write a new Charter. It will incorporate the goals of the Working Group, as discussed in these minutes. Printer Access Protocol Proposal The reaction to PAP was mostly positive. The consensus was that it is adequate for a base. There was significant discussion on the following points: Security There was significant concern over security, of several varieties: 1. Authentication of the job, to the printer; to ``keep students from printing on the Chancellor's printer''. 2. Encryption of the job, on its way to the printer. 3. Mechanisms to support military security, e.g., printers that might print secret documents. Items 1 and 2 received the most interest. We need to work with the SAAG on this. Standardization of Keywords PAP uses ASCII strings to report on resources and capabilities. The possible values and their meanings are not defined in the specification. For example, the values reported by the ``show'' command are not documented. This must be fixed -- implementation isn't possible as the document stands. Support for Requesting Facilities. PAP provides, with the ``show'' command, facilities to report the 3 availability of various resources, such as paper trays, fonts, and page description languages. It was pointed out that there was no way to request that these resources be used. Trewitt observed that most PDLs provide these mechanisms. The apparent concern is to provide a way to set the font, paper size, etc., for *TEXT* to be printed on a printer. This seems to be asking for a ``text'' page description language. The possibility that was discussed was to define command(s) and options which would request resources. Trewitt feels this is a bad idea, as these requests could get in the way of the facilities of more advanced PDLs. He suggests a more favorable approach would be to formalize the concept of a ``text'' page description language, and define mechanisms within that to request paper size, etc. More discussion on the mailing list is definitely required. Internationalization An observation was made that it was important that where parameters are supplied by users, (e.g., everything in the ``soj'' command), it be possible to use 8-bit character sets so that customers in Sweden (for example) would be able to have their name appear properly on the banner page. Palladium Digital Equipment (in the person of Richard Hart) has ``set aside'' Palladium for consideration, for the moment. Palladium's upper layers are making good progress through Posix. Palladium's lower layers depend upon some RPC. Since there isn't currently an Internet-Standard RPC (and there aren't any signs of one appearing soon), he decided that now was not the time for standardization in the IETF forum. Son of LPR This still leaves us with the question of: ``What do we do to provide better user services for printing?'' PAP only provides Spooler->Printer services. There is still a need for User->Spooler and Spooler->Spooler services. Lpr/lpd fills this niche right now, and Palladium may fill the void later, but right now we have nothing that anybody particularly wants. We discussed the possibility of ``fixing'' lpr/lpd. There wasn't any great consensus that it is a worthwhile starting point. Upon reflection it did not seem that anyone liked that idea. So, what we *will* do, 4 before the next IETF meeting, is to come up with a list of services that we want to see available from this protocol. 5 Attendees Anne Ambler anne@spider.co.uk Philip Budne phil@shiva.com George Conant geconant@eng.zyplex.com Robert Gilligan gilligan@eng.sun.com Russell Hobby rdhobby@ucdavis.edu Joshua Littlefield josh@cayman.com John Lunny jlunny@twg.com Donald Merritt don@brl.mil Oscar Newkerk newkerk@decwet.enet.dec.com Brad Parker brad@cayman.com Michael Reilly reilly@nsl.dec.com Bill Rust wjr@ftp.com Richard Smith smiddy@pluto.dss.com Glenn Trewitt trewitt@nsl.pa.dec.com John Veizades veizades@apple.com Steven Waldbusser waldbusser@andrew.cmu.edu 6