Minutes of IPP Working Group Meeting October 27-28, 1999 1. Meeting Attendees Lee Farrell Canon Information Systems Rick Yardumian Canon Information Systems Ben Brezinski Hewlett Packard Sandra Matts Hewlett Packard Ron Bergman Hitachi-Koki Vinnie Finn Kodak Jim Vitkus Kodak Don Wright Lexmark Thomas Nielson Microsoft Hugo Parra Novell Ying Nancy Chen Okidata Paul Moore Peerless Gail Songer Peerless Chuck Adams Tektronix Tom Hastings Xerox Carl-Uno Manros (Chair) Xerox 2. Day 1 Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics: * IPP Extensions * IPP Notifications * HTTP-based Notifications * IPP MIB * Set 2 Operations * IPP/1.1 Bakeoff During the agenda discussion, it was decided (again) that Tom Hastings would pursue the registration of different vendor document print languages as MIME types. He will issue e-mail on the progress of this effort. 2.1 Notification Delivery Methods Tom referenced his Oct 26, 1999 e-mail that lists different IPP Notification delivery-methods. Tom briefly reviewed each method with the group. Based on various comments and questions, he updated the descriptions in the document (on the fly) for subsequent distribution. During the review, a few additional methods were identified, resulting in the following list: 1. Server-directed client polling 2. Server push using MIME-multi-part responses 3. In-band Get-Notifications operation 4. In-band Get-Notifications operation with Subscription Ids 5. In-band Get-Notifications without Subscription objects 6. In-band Get-Notifications with queued events 7. In-band Get-Notifications with queued events-but only one event per Get-Notification 8. In-band Get-Notifications with queued events-with all events in one Get-Notification response 9. HTTP-based IPP Notification Delivery Protocol 10. HTTP-based IPP Notification Delivery 11. SNMP traps over UDP 12. SNMP informs over UDP 13. UDP delivery as Send-Notifications without response 14. UDP delivery as Send-Notifications with response 15. TCP delivery as Send-Notifications without response 16. TCP delivery as Send-Notifications with response 17. Email 18. Email with only Human Consumable 19. Email with both Human Consumable and Machine Consumable 20. Instant Messaging 21. Paging 22. Configured operator paging 23. Configured operator delivery 24. Configured operator delivery with event filter 25. Configured operator delivery with reasons filter 26. Alternatives 1,2, and 3 with all Subscriptions For most of the remainder of the day, the group attempted to identify "pros and cons" for the above notification methods, which were later compiled and distributed by Tom. During the review, there was much discussion about whether we would be creating our own instant messaging method(s), or wait to adopt the method that the IETF is intending to define. Day 1 meeting adjourned. 3. Day 2 3.1 Set 2 Operations Tom Hastings led the group in a review of the latest updates and (several of the) Issues in the October 22 draft of the "Set 2 Operations" document. He noted that an Interpreter object has been added to the document, and reviewed it in detail. As explained in the document, the Interpreter object models the document format interpreters that are contained in the Printer object. Its purpose is to model those Printer attributes whose value depends on which interpreter is being used to process the document. One of the attendees pointed out that this new object has no affect on what is sent over the wire in the protocol. When Tom asked if people want to add the Interpreter object, only one person indicated interest. Therefore, the group decided against adding the object. After reviewing the new operation attribute for Pause-Printer, "when", the group decided that the default behavior for the attribute should be "now" instead of "after-current-job". It was also agreed that each operation should have an explicit list of allowed values for the "when" attribute, with a default value identified. ISSUE 1: Can a client determine the values of "when" that are supported for operations? The group agreed no. As an attempt to avoid specification complexity, Paul Moore suggested that the Printer must be in the paused state before it can be reset. At one point in the discussions, Paul pointed out that the new operations create a significant shift from the current IPP model. The new items seem to be very concerned with the printer device behavior. Previously, the specific device(s) had been hidden within the IPP Printer object. Paul proposed that for the fan-out case, it would be possible to obtain the URIs for each of the individual devices known/supported by the IPP Printer. Further, he suggests that the downstream printers should also be IPP Printer objects. The term "Subordinate Printer" was suggested to describe these downstream printers-only to be used in the fan-out case. It would be up to the proxy Printer object to determine if it wants to expose any of its Subordinate Printers. This led to a long discussion about possible modeling alternatives that would adequately address the issues of controlling the logical printer-and the resulting effects on the physical printer(s) involved. Paul recommends that it would be better to define explicit operations intended to affect the physical devices, rather than to overload the operations defined for the abstract logical printers. This led to the (unanswered) question of whether the IPP model should introduce a "Physical Device" object that would reflect/affect the behavior of the "hard metal." What about the "fan-in" case? ISSUES 2-6 were deferred until the above topics are resolved in more detail. ISSUE 7: A few attendees commented that obtaining printer-settable attributes (for displaying to the user) could be achieved through the use of UPDF. There was a discussion of whether or not it would be appropriate to mandate a list of attributes as settable. Carl-Uno suggested that it might be restricted by privilege level and access control. The group agreed to reverse the decision made at the previous meeting, and keep "printer-settable-attributes" and "job-settable-attributes". ISSUE 8: No longer an Issue because Interpreter object is gone. ISSUE 9: See Issue 1. ISSUE 10: No. ISSUES 11, 12: Not discussed. ISSUE 13: No. It was suggested that the Set 2 Operations document should be split into two documents-one for "device operations" and one for IPP Printer operations. However, until a device model is more clearly defined, it will be difficult to agree on what qualifies as a device operation. Tom will issue a list of which new operations he thinks should be created, renamed, and/or defined as "device" operations. One person questioned whether some of the operations should just be separately registered as vendor-specific extensions. The group agreed that Space-Current-Job and Non-Process-Run-Out should be separately registered. 3.2 Notification Delivery Methods - cont'd Tom Hastings distributed a copy of a table he created to summarize the "Pros and Cons" discussion of the different notification delivery methods. This table was also distributed in an e-mail message on Oct 27. After Tom explained how to interpret the results of his summary table, he noted that the "winning" method seemed to be e-mail based. Almost everyone was surprised at this conclusion-and suggested that the table entries and/or evaluation formulas might need to be re-examined. (For instance, should all requirements be given equal weight?) Paul Moore suggested that the group should select one machine readable method to focus on first and "go with it." Several people seemed to agree. Hugo advocated that HTTP should be selected. 3.3 HTTP-based Notifications Hugo Parra led a review of his proposal for an HTTP-based Notification Delivery Protocol. There was much disagreement about which MIME type would be appropriate for the Send Notification request-application/ipp, application/ntfy, etc. ISSUE 1: The group agreed to allow a single notification to have both Human Consumable and Machine Consumable form. ISSUE 2: Paul suggested that we should use ipp:// as the notification protocol scheme. He believes we might want a richer set of communication exchange in the future, and it would be better to keep it all within the same scheme. Most of the group eventually seemed to agree, but Carl-Uno expressed strong disagreement, believing that the IESG would not accept it. ISSUE 3: The group agreed to add a success status code that requests the subscription to be canceled. ISSUE 4: The group agreed to keep the entries. Hugo will update his document and redistribute it for additional review before submitting it as an Internet-Draft. 3.4 IPP Extensions Carl-Uno explained that there will be a BOF meeting for IPP Extensions at the December IETF meeting. The proposed Charter will identify the following items as the major goals of the new Working Group activity: 1. Notifications 2. IPP Optional Operations (for Operators and Administrators) 3. IPP Extensions for Advanced Production Printing A question was raised about whether item 3 above is really appropriate as an IETF activity. Given that it does not really affect the network protocol, but focuses exclusively on printing applications details, it was suggested that it might be more appropriate to develop this item as a PWG/ISTO specification. The same question was raised about item 2, but to a lesser degree. 3.5 IPP Notifications Tom reviewed the four remaining Notification specification Issues that he listed in his October 18 e-mail. ISSUE 1: Deferred. ISSUE 2: The group agreed to change the model to allow notification delivery methods that are request and response. ISSUE 3: The answer to this Issue depends on the specific method. ISSUE 4: It is ok that "job-uri" isn't defined for use with the Create-Job-Subscription operation-as long as it is consistent. ISSUE 5: The group agreed to be consistent with other operations by creating two groups and copying attributes as appropriate. 3.6 Document Numbers Tom and Carl-Uno engaged in an exchange of interpretation and opinion regarding a recent e-mail thread on a proposal to include a document number operation attribute. However, they did not reach any conclusion and the topic was deferred for further discussion via e-mail. Should we create a facility to allow the client to determine whether a printer can accept multiple documents in parallel? How about indicating a maximum number supported? Tom will work with Carl Kugler (and Michael Sweet?) to generate a more detailed proposal for group review. 3.7 Notifications Using SNMP Before the meeting concluded, Tom provided a review of Ira McDonald's proposal on using SNMP traps to deliver notifications. It was noted that the proposal includes a new ipp scheme, "ipp-snmp://". Ron Bergman thought that the scheme could be more generically applicable, and suggested that it should be renamed to something like "snmp-trap://". He volunteered to investigate if such a scheme already exists. There was no consensus reached about the perceived usefulness of the proposal. One person expressed the opinion that very few companies (i.e. less than two) would choose to implement it. IPP meeting adjourned.