IPP Meeting Minutes September 22-23, 1999 Denver, Colorado Attendees: Shivan Albright - HP Stefan Andersson - Axis Ron Bergman - Hitachi Koki Dennis Carney - IBM Nancy Chen - Okidata Bob Herriot - Xerox Henrik Holst - i-data David Kellerman - Northlake Software Carl Kugler - IBM David Kuntz - HP Greg LeClair - Epson Dwight Lewis - Lexmark Harry Lewis - IBM Carl-Uno Manros - Xerox Jay Martin - Underscore Sandra Matts - HP Peter Michalek - ShineSoft Sustems Hugo Parra - Novell Eric Randon - Peerless Stuart Rowley - Kyocera Gail Songer - Peerless Hideki Tanaka - Cannon Shigeru Ueda - Cannon Atsushi Uchino - Epson Bill Wagner - NetSilicon/DPI Trevor Wells - HP Craig Whittle - Sharp Labs Don Wright - Lexmark Michael Wu - Heidelberg Digital Peter Zehler - Xerox Rob Zirnstein - Cannon Chair: Carl-Uno Manros, Note taker: Ron Bergman IETF Update: The last call of the IPP 1.1 documents expired early August and the document is now being reviewed by the security experts. No response has been returned to Carl-Uno’s request for status. JINI Print API Activity: The JINI APIs are based upon the IPP model and there have been four unique APIs proposed. Rather than try to pick one of the proposals, it was decided to work on the problems that were uncovered during the development of each. There has been a general agreement to incorporate Windows type drivers in the printing systems. There is also an issue as to how much type checking should be included in the API. Extensive job checking can have a considerable negative impact on the amount of code that needs to written for a gateway and also limits the extensibility of the code. ‘printer-state-reasons’ suffix: The default suffix of "error" is not applicable with the printer-state-reason of "none", as outlined by Carl Kugler. Tom Hastings has proposed two alternatives. The first adds a specific default associated with each printer-state-reason that is specifically define in the specification. The second alternative states that the absence of a suffix is implementation dependent and ambiguous and the suffix must be included to remove the ambiguity. Carl Kugler proposed a third alternative that exempts "none" from having a default suffix or requiring any suffix. This third alternative seemed to be the most acceptable to the group. Carl will send a formal proposal to the mailing list to see if anyone has any objections to this proposal. Version 1.1 Implementer’s Guide: Henrik reviewed the changes that were made to the document since the last issue. The word version of the document provides many useful reference tables and flow charts, but these will be difficult to include in the text version of the RFC. Carl Kugler suggested that an example be added that shows that the ipp scheme and the http scheme are interchangeable if port 631 is included with an http scheme. Carl also suggested that all the possible URL matching algorithms be included in one place in the document. URLs can be extensively modified by a proxy and including all the possible variations with a string match is not a good design. After much discussion it was agreed that the Printer URI should not be used for any validation of the packet. The text in the model document is intended to convey the fact that the URI must be valid for the request to reach the printer. If the request has found its way to the printer, the URI should not require validation. Henrik will revise the document to reflect this agreement. A statement will also be added to the document that it is applicable to IPP 1.0 as well as 1.1. Notifications: IPP Event Notification Specification - Alternative: Bob Herriot reviewed the differences between the previous specification and this version. The primary change is to have per-job subscriptions use the same model as the per-printer subscriptions. Hugo suggested that job subscriptions with a create-job operation be mandated, and that the operation create-subscription for jobs be optional. It was further proposed that the create-subscription operation be split into a create-printer-subscription and create-job- subscription and the second be optional. Issue 1: Postponed. A mandatory notification transport will be decided at a later date. Issue 2 / 3: A chaotic discussion resulted in several proposed solutions. The agreed solution is to require all transports to support machine readable (application/ipp) and also provide an indication if human readable text is available. Human readable text can include plain text, HTML text, etc. For those transports that can return human readable text, then that option can be selected. MIME types will be used to define the text formats available. A new optional attribute will be defined to provide this information. Issue 4: Agreed to change the names to notify-charset and notify-natural-language instead of the names that were proposed in the issue description. Issue 5 / 5a: The proposal presented in the document was rejected. An error or warning message could be returned if the subscription cannot be accepted. Another proposal was made to add a new notification-fidelity attribute. Issue 6 , 7, and 8: Agreed to change as presented. Issue 9: Agreed that job-id is not necessary and that there is no real need to get all job subscriptions. Issue 10: After a long discussion on the need for "collections", it was agreed to keep the concept of collections in the Notification Specification and not make the changes proposed by Ira. The vote to keep collections was 11 to 0 with 6 abstentions. Issue 11: Rejected, no change. Issue 12: No decision at this time. Issue 13: Yes, agreed to incorporate the change. Issue 14: It was argued that job-state-reasons is useful in a job-progress event. It was agreed to keep both job-state and job-state-reasons. New issue 1: There may be a desire to know the number of pages, sheets, etc completed at the end of the job and these attributes should be returned in job-completed notification. It was agreed to change job-impressions-completed and job-sheets-completed from optional to required for both job-progress and job-completed notification types. New Issue 2: A request to add total impressions to job progress so the application can build a "gas gauge" to show job progress. Dennis Carney (IBM) will submit a formal proposal to be reviewed. New Issue 3: It was agreed to change subscriber-user-name (number 14 in table 4) to optional under the column "all others". HTTP Based Notification Protocol: Hugo presented the first draft of his proposal for Notifications over HTTP. There is some concern regarding the terminology used in the document. The terminology should be identical to that used in the IPP Event Notification Specification. The problem with the use of the HTTP transport across firewalls was discussed. Hugo presented two scenarios, the first with only a notification recipient and the second with notification server that would serve multiple notification recipients. The notification server would reside behind the firewall with the notification recipients. (This is similar to the configuration currently in NetWare.) After a short discussion it was concluded that more work is required on this topic. There are two options presented in the document for the presentation of the actual notification. The first uses two new IPP attributes that define 1) the machine readable part with the value as a collection and 2) the human readable part. The second option simply uses the presently defined attributes in the IPP Event Notification Specification with the addition of a new attribute for the human readable text (human-readable-report). The use of a new scheme was debated. There was no agreement that a new scheme will be necessary. Other Documents: IPP Job Progress Attributes: A quick review of the document was performed with the following agreements: Continue to use enums instead of keywords and use the IPP out-of-bound ‘unknown’ instead of -2. IPP Set 2 Operations: Harry Lewis provided an introduction and overview of the document and a justification for the need of these additions. Issue 1: The concept of a ‘when-values-supported’ was rejected. The printer will do the best it can to support the request. Issue 2: The decision was to remove the queries for settable attributes. To determine if an attribute can be set, just try to set it. A new error code will be added to indicate an attribute is ‘not-settable’. Issue 3: After a long and convoluted discussion, it was agreed to include the new attribute ‘printer-controls-other-protocols’. The text will also clarify that this applies to both the printer as well as jobs. Issue 4: It was agreed that some administrative functions should be added to IPP and that conflicts among management applications and methods will occur. There seems to be no easy way to prevent this and it should be accepted. The current operation should always be accepted regardless of the method presented to the printer. There is presently no official PWG policy as to what level of management IPP should and should not support. There was some discussion as to whether a policy is needed or should we just keep pushing the limit. Issue 7: A new out of band "not-settable" value will be added. Issue 9: There was significant confusion as to the meaning of shutdown. If a shutdown operation halts communications to the printer a restart is not possible. It was agreed to include restart attributes ‘restart-to-standby’ (requires a two step process), ‘restart-fully’, and ‘restart-sync’. Harry will attempt to update the document and submit for approval. Issue 21: An editorial change only and agreed to include. IPP Finishing Attribute Values Extension: The document changes have been accepted as presented except that the 1.1 version number will be removed. These extensions apply to both 1.0 and 1.1. IPP Media Attribute Values Extension: The document has been accepted as presented. IPP MIB: Ira McDonald and Tom Hastings expanded Ira’s previous SNMP Notifications transport document into a full IPP MIB. The group consensus was that an IPP MIB is not necessary, not required, and not desired. No one in the group expressed any desire to continue work on this document. There were also several comments that the document has significant overlap with the Printer MIB and the Job Monitoring MIB. There is no reason to create a new MIB to repeat existing objects. Next Bakeoff: Peter Zehler anticipates the next bakeoff should occur second quarter next year. This function should cover IPP 1.1 plus the notifications feature. A host for this function is being solicited. IETF Participation: The next IETF meeting is in Washington D.C. the week of November 8-12. Carl-Uno asked if there was interest in having a BOF for the IPP notifications and extensions and generating a new working group charter. It was suggested that the IETF and the PWG (a program of the IEEE ISTO Standards and Technology Organization) cooperate on future standards effort. There was no agreement to the IPP BOF issue. IPP Meeting Minutes September 22-23, 1999 Denver, Colorado page 5