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 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 a 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.