1. IPP Minutes -- August 19-20, 1998 Carl Uno-Manros opened the IPP meeting. He presented the proposed agenda topics: - Discussion of any further feedback from the IESG on the latest IPP submissions: - IPP scheme - security parameters for IPP scheme - Implementor's Guide -- resolution of issues not yet resolved - Proposed new operations for PWG registration - Proposed new attributes for PWG registration - Accessing MIB information over IPP - Notifications -- presentations and report from WISEN - Testing and bake-off on September 23-25 - SDP requirements - New operations 2. Feedback from the IESG on the Latest IPP Submissions Carl-Uno identified the two most recent issues that have been discussed with the IETF Area Director. He referenced the document that was submitted to the IESG discussing the newly proposed IPP scheme. The second issue--pertaining to the use of security parameters--has been addressed in a proposal from Xerox in an e-mail message about Security parameters for IPP scheme. The IESG has still not provided any official feedback on the IPP document submissions--however Keith Moore (IETF Area Director) has hinted that there continues to be concern about security issues related to the protocol. Carl-Uno has not yet received any commitment from the Security Area Director to attend the IPP session to discuss security issues at the IETF meeting next week. It was suggested that the proposed solution of using security parameters should be included in the proposal for the IPP scheme, but no agreement on this suggestion was reached. 3. Implementor's Guide -- Issues Not Yet Resolved Carl-Uno distributed a first draft of the IPP Implementor's Guide. He stressed that this is a PWG document--not an IETF document. Harry Lewis suggested that a date should be added to each of the Questions in the document. Carl-Uno agreed. It was also suggested that each Question be assigned a number (or other identification) for easy reference. Perhaps the document will also have line numbers assigned as well. The group then reviewed each of the Questions and attempted to provide and agree on Answers. 3.1 Model & Semantics Question 1 -- The group agreed that the Answer should be: "Yes, further attributes may be added in the future. Capability might be provided by post processing outside the printer." Question 2 -- Answer: In IPP v1.0, other objects are "hidden." We might consider this for a future version. Question 3 -- After examining the question, the group does not agree with Carl Kugler's last paragraph as an attempted answer. Bob Herriot will draft a proposed response for this issue, and submit it to for consideration by the group. Question 4 -- The group agreed to Tom Hasting's suggestion proposed in the Question. Question 5 -- Answer: The current document addresses this Question already. The printer will do the best it can to convert between each of the character sets that it supports--even if that means providing a string of question marks because none of the characters are representable in US ASCII. [Some people noted that the problem is not likely to occur in most practical situations.] Question 6 -- [The group feels that this Question does not belong in the Implementor's Guide. The Question will be removed.] Because the definition of "pages-per-minute" is so varied--based on quality, color, page content, etc.--a single-valued attribute will not be added. Instead, people are encouraged to generate a proposal for addressing this issue. Question 7 -- Answer: Yes, it is really necessary to keep the "Validate-Job" operation as a MUST to implement. Question 8 -- Answer: No. Question 9 -- The group agreed that Harry's response (contained in the document) will be re-worded and used as the Answer. 3.2 Encoding & Transport Question 1 -- [It was noted that the document should say, "A client MUST NOT expect a response from an IPP server until after the client has sent the entire request."] Although a client can receive a "100 Continue" response, it should just throw it away. Bob Herriot will consider drafting an appropriate Answer for this item. After receiving some additional input from Carl Kugler, the group believes that he is interpreting the statement as if it refers to the HTTP layer--not the IPP layer. One person suggested that the document should be clarified to say, "A client MUST NOT expect an IPP response from an IPP server until after the client has sent the entire IPP response." Question 2 -- [Carl-Uno noted that the Discussion in the document is not relevant to the Question. The discussion will be removed, or attached to a different Question (see below.)] Answer: Yes, the "resource" is either an IPP Printer or a Job. However, the group was unable to address the remaining parts of the Question. They will request Carl Kugler to provide further clarification. It is (at least) unclear what assumptions are being made. Discussion 2 -- [Even though there is no explicit Question related to this Discussion, the group still discussed the topic of port number support within the IPP scheme.] The group is still debating Keith Moore's words about what is meant as "default support" of port 631. Specifically, people are arguing whether or not a Printer needs to be "pre-configured" in the box to support port 631 to qualify as "default support." Bob Herriot will attempt to provide an interpretation and re-wording for inclusion in the Encoding & Transport document. 3.3 Interoperability Bake-Off Question 1 -- Answer: Accepting client requests that use the "chunked" transfer encoding will be tested at the Bake-Off. For testing purposes, it is very desirable that each implementation can turn on and off "chunking." This would allow testing to continue independently of the chunking issue. 4. Testing and Bake-Off on September 23-25 Pete Zehler discussed the Bake-Off plans, identifying some of the logistics and connection configurations involved. He referenced a Test Plan document that he had written, and reviewed several of the Issues listed in Section 3. Pete says that there will be a couple of scripts posted for helping to generate the necessary test sequences. The scripts will be accompanied by Readme files that explain their usage. The scripts are organized in directories associated with the test tool being used. He quickly reviewed the various test scenarios that are listed in the plan. Pete plans to have scripts developed (and posted) for each of the test items. About 10 organizations have notified Pete of their interest to participate in the Bake-Off. The following list has been published via e-mail: PARTICIPANTS: Organization # of participants IPP Component Auco 1 Printer Epson 2 Client, Test Suite Fuji Xerox 1 Printer IBM 2 Client, Printer i-data 1 Printer Hewlett Packard 2 Client, Printer Lexmark 3 Printer Microsoft 2 Client, Printer Novell 1 Printer DPI/Osicom 1 Printer Ricoh 1 Printer Sharp 1 Printer Sun 1 Printer Tektronix 3 Printer TRCS 1 Test Suite Xerox 5 Client, Printer, Test Suite During the discussion, Pete identified the following issues and action items that need further attention: - Unix box for testing? - Send out list of organizations - Send out test plan - Can we move existing machines? - What about shipping information (to Microsoft)? - What is location (i.e. building) of Bake-Off? - Contact person at Microsoft? 5. Proposed New Operations for PWG Registration Tom Hastings led a review of the document, "Internet Printing Protocol/1.0: Additional Optional Operations -- Set 1" Tom noted that the Restart Job operation could cause problems for some accounting systems. Because the same Job Id is used--and accounting attribute values are re-set to zero, this may be difficult for some systems to handle properly. The group discussed why we really need both Restart Job and Reprocess Job operations. There did not seem to be a clear consensus reached. However, at a previous meeting Paul Moore indicated that he wants to provide a Restart Job capability within Microsoft to be consistent with existing capability. For supporting more complex accounting capabilities, other implementations would need the Reprocess Job operation. Harry Lewis requested that the requirements should be more clearly identified to provide justification for the new operations. There was much discussion about the job state transition table that shows the effect of receiving a Restart Job operation. As a result of the discussion, Tom volunteered to work on defining a single operation that will re-print a Job. He will include an input parameter that will indicate to which state the Job will transition (i.e. whether the Job will go to a Hold Job state or not.) During discussion of the Pause Printer operation, it was suggested that a stronger statement should be included to clarify that this operation is primarily intended for administration purposes. Tom will clarify the difference between "Purge" and "Cancel". Tom will try to update and re-publish the document within the next two weeks. Tom then led a review of the document, "Internet Printing Protocol/1.0 Extension: Additional Optional Operations -- Set 2". Two additional operations have been proposed: - Reject Jobs -- causes the IPP Printer object to reject subsequent job create operations - Accept Jobs -- causes the IPP Printer object to accept subsequent job create operations Would the operations affect the behavior of LPR jobs that are communicating directly with the device? It was suggested that the specification should only define behavior for IPP communication--anything else is out of scope. As discussions continued, people felt that it was premature to introduce the proposed operations. This was primarily because they seem to address administration features, without the group having agreed upon a clear set of requirements for IPP Printer administration support. In response to this concern, Tom volunteered to generate a draft of Administrative Requirements. Don suggested that we should make a clear distinction between IPP Administration and Device Management. Should we be using IPP or SNMP for administration? What message does the PWG want to give to the industry in terms of future direction(s)? There was no consensus on the answers to these questions. 6. Mapping Between IPP and IFAX Ron Bergman reported on his investigation into the possibility of mapping IPP and IFAX. He examined the following two scenarios: 1. tunneling an IFAX document within IPP 2. transmission of an IPP document as a Fax After considering the second scenario, Ron thinks that it has little significant value. However, to be complete, the group feels that we should examine both directions of the gateway function. Ron briefly reviewed some of the IFAX attributes that would require additions (or changes) to IPP. In order to support TIFF, additional keyword support would be required. In summary, Ron does not think that this should be a difficult effort. Ron will post a document that discusses his findings within the next two weeks. 7. Proposed New Attributes for PWG Registration Carl-Uno discussed additional extensions requested by Xerox for additional attribute/attribute values to support Finishing. He distributed a document on the subject. Carl-Uno wants to know if the attributes are general enough for PWG adoption, or if they should remain as Xerox-specific extensions. Several people wanted to know how closely these items were aligned with the FIN MIB content. It was recommended that Xerox should make another revision to their document after making it more consistent with the FIN MIB. There was much debate about the set of values suggested for output bin. People are concerned that a common list of "standard" values will be difficult to establish--there are too many variants used by different vendors. Tom explained that the method proposed allows for vendor extensibility. 8. Collection Attribute Syntax The third IPP extension document that Tom reviewed with the group was a proposal for the "Collection" attribute syntax. Tom explained the major points of the proposal. Bob Herriot suggested that the maximum size of a Collection of Collections could be larger than 1024 octets. There were no other comments or questions about the document content. 9. Accessing MIB Information Over IPP Tom Hastings discussed a few issues related to the document, "Summary of 'IPP Device Object and MIB access', Version 0.04". He attempted to resolve some of the issues with the group, and he plans to update the document accordingly. 10. Notifications -- Presentations and Report from WISEN Carl-Uno announced that a "Birds of a Feather" (BOF) session on Event Notification Service will be held at the IETF Plenary. The group wants to generate a generic notification service that has widespread applicability over the Internet. A Workshop on the topic was recently held in Irvine, with several presentations given. At least one of the solutions considered was using a "beeper" network. Some people think it might even be possible to use the beeper service--as it exists today--to support notification delivery. 11. IETF Plenary Meeting Agenda The major agenda item planned for the IPP WG session is to discuss the IETF/IESG feedback on the IPP document submissions. Several people are concerned that if there is no feedback, there will be no reason to attend the session. Carl-Uno sent an e-mail to the Area Director (Keith Moore) saying that there might not be any meeting if the group does not receive any IESG feedback. (The IPP session is currently scheduled for Wednesday, August 26.) During the second day of the IPP meeting, Keith Moore informed Carl-Uno that he has not yet received a reply from the Security Area Director. 12. SDP Requirements This topic was not addressed. IPP meeting adjourned.