Report from the IETF IPP WG Meeting in Memphis on April 8, 1997 Roster ------ Samir Albadine Atlas albadine@global-0ne.atlas.fr Harald T. Alvestrand Area Director harald.t.alvestrand@uninett.no Ron Bergman Data Products rbergma@dpc.com Dave Crocker IMC dcrocker@imc.org Lee Farrrell Canon lfarrell@cissc.canon.com Jonathan Greenfield greeny@pobox.com Erik Guttman Sun eguttman@eng.sun.com Tom Hastings Xerox hastings@cp10.es.xerox.com Robert Herriot Sun robert.herriot@eng.sun.com Stephen Holmstead HP stephen_holmstead@hp.com Peter Hornby Unisys peter.hornby@unisys.com Takahito Inoue inoue@iij-ad.jp Scott Isaacson Novell scott_isaasson@novell.com John Klensin MCI klensin@mci.net Alex Latzlo latzlo@rutgers.edu Scott Lawrence Agranat lawrence@agranat.com Toru Maeda Canon maeda@ffm.canon.co.jp Carl-Uno Manros Xerox manros@cp10.es.xerox.com Larry Masinter Xerox PARC masinter@parc.xerox.com Dan McInture Boeing daniel.d.mcintyre@boeing.com Keith Moore Area Director moore@cs.utk.edu Andy Mutz HP andy_mutz@hp.com Omey Nandyal onandyal@openport.com Mike O'Dell UUNet mo@uu.net Charles E. Perkins Sun cperkins@corp.sun.com Rich Petke r.petke@csi.compuserve.com James Rafferty jrafferty@worldnet.att.net Yoshihito Shimazu shimazu@iij-ad.jp Judith Slein Xerox slein@wrc.xerox.com Randy Turner Sharp rturner@sharplabs.com Juerg von Kaenel IBM juk@watson.ibm.com John Wenn Xerox jwenn@cp10.es.xerox.com Don Wright Lexmark don@lexmark.com Lloyd Young Lexmark lpyoung@lexmark.com Steve Zilles Adobe szilles@adobe.com Chair's Summary for the Area Directors (written By Carl-Uno Manros & Steve Zilles) -------------------------------------- The meeting was attended by a little over 30 participants, about half of which were active WG members. The agreed charter was presented and presentation and discussions were held about the five I-Ds relating to the IPP work. 1) Requirements for Internet Printing It was made clear that this document describes some scenarios and requirements that go beyond the scope of the first version of the IPP protocol, e.g. the location of printers based on search criteria. 2) IPP Model & Semantics It was explaned that this document is the key document for IPP and will contain all the semantics related to objects, attributes, operations, and transfer neutral syntax. It was made clear that this will require further work before it is complete and consistent. A number of issues are still outstanding. 3) IPP Directory schema It was explanained that this is mainly a subset of attributes from the modeling document suitable for inclusion in a directory, and is intended to be neutral to the chosen directory implementation. 4) IPP Protocol Most of the discussion was around this proposal, which outlines two different mappings of the model to a transport, one which is browser oriented and one which is a more direct mapping onto transport. Two levels were described, one at which model data gets packaged into some form of MIME (either form-data or a new application/ipp format) and one where these MIME types get transferred using either HTTP 1.1 or a "to be defined" subset thereof. Suggestions from the audience included selecting only one mapping, or to make the browser mapping an extra layer on top of the other mapping. Work will be intensified on this subject, supported by active prototyping. 5) IPP Security The security document at this stage describes scenarios and requirements for generic security services. Some suggestions were given about Internet security protocols that potentially could meet the requirements. Meeting Minutes --------------- Internet Printing Protocol Working Group at the 38th IETF These minutes were recorded by Don Wright. The meeting was called to order by Carl-Uno Manros at 9:03 AM CST on April 8th at the Peabody Hotel in Memphis, Tennessee. Planned agenda: 1) Introduction of WG Charter and Internet-drafts 2) Protocol 3) Security 4) Requirements 5) Model and Semantics CHARTER: Carl-Uno reviewed the WG charter including the lists of: - Advisor, Chairs, Editors - Current Drafts The goals and background information of the charter were then reviewed. (Carl-Uno's charts will be available as a part of the proceedings). A question was asked as to what directory methods would be used. The current plan is to define the directory schema so as to be directory neutral and to be optional. Since the original IPP BOF at the last IETF meeting, significant security requirements have been added to the charter. A question was raised as to how the directory information would keep up to date when used in a cached environment. Since IPP is not defining the directory access method only the schema, IPP will not be addressing the area of caching of directory information. Many people felt that the directory work should be a milestone after the protocol is done; however there were others concerned that while the actual document could be done later, it needed to be considered while working on the model. The WG will produce recommendations for inter-operation between IPP clients/servers and LPD clients/servers. Charter Milestones: March 97: Internet Drafts: requirements, model, protocol, and directory schema May 97: Several implemented prototypes August: Requirements I-D to IESG as informational RFC Mapping IPP/LPR mapping as informational RFC Other documents submitted as RFCs for Proposed Standards Contact Information: Discussion list is: ipp@pwg.org. To subscribe: ipp-request@pwg.org Archive is: ftp://ftp.pwg.org/pub/pwg/ipp Web Server is: http://www.pwg.org/ipp/ A long discussion on what should be covered within the directory schema. One of the major potential problems identified was how to include access control as a part of the information available through the directory. The scope of IPP at this time does not cover administrative functions like job accounting. PROTOCOL: Steve Zilles presented an outline of the general direction the group is going in the area of "protocol." (Steve's charts will be a part of the proceedings.) A concern was raised that if multiple, alternative ways are defined to do something, we will fail. This comment was directed at the current direction to perhaps support Application/IPP and Multipart/FormData as well as support both HTPP/1.1 and some new IPP TBD. The current protocol issues Steve identified are: 1) Status inquiries during data transmission - posting all the data at once --- versus--- - create job, send data 2) What must the server implement? - full HTTP/1.1 - IPP subset of HTTP/1.1 (non-caching, origin server) - TBD protocol Questions: - Can we really subset HTTP/1.1? - Work level difference between creating a new protocol versus subsetting? - Harald Alvestrand. presented a concept of layering and a HTTP/HTML presentation of data to be send via or received from an IPP protocol. Interoperability issues with potentially two protocols and syntaxes are: 1) One protocol, two syntaxes - server must implement both 2) Two separate protocol - formdata over HTTP - application/ipp over tbd - server may implement either 3) Does the request format determine the response format? 4) How are the operations coded? - in the formatted data - in the protocol header - in the URL that is the target. SECURITY: Carl-Uno presented the work being done on security for IPP. (These charts will be available in the proceedings.) The type of attacks that could be deployed against IPP were described including masquerading, eavesdropping, tampering, replaying, denial of service, document malicious content code (embedded programs in the print job), liability and provability of service. All these were mapped against security services like client authentication, server authentication, data confidentiality, data integrity, non- repudiation and timestamping/nonces. There were some areas of the chart that need to be updated with additional "yes"es. "Signing" was identified as something that has been very useful as a combination of authentication and integrity. The group has looked at a number of security services being investigated including HTTP/1.1 (Digest Authentication -- RFC 2069), SSL(V2), SSL(V3) and LDAP. Additional security service suggested to be examined include sHTTP, SMIME and PGP. Simple security service (like LPD user name) would probably not be appropriate for a standards track document (Keith Moore.) Adequate security must be defined but the security level may be negotiated between the client and the server. Harald A: Decisions on security should be made by the working group not by the Area Directors but having no security will probably be a problem. MODEL DOCUMENT: Harald A. expressed his opinion that while the model document is very large, it seems incomplete. He had several comments and will document them in detail to the distribution list. Due to a lack of time, the Requirements document was not discussed. The meeting was adjourned at 11:35AM CST. -----------------------------------