DRAFT IPP Working Group IETF Meeting Minutes April 1, 1998 Los Angeles, California The meeting of the IPP WG at the IETF plenary was held on April 1, 1998 1:00-3:00 PM. The attendees were: 1. Agenda 1) Requirements for notification 2) Directory features 3) Other future work 4) Area Directors questions about IPP 2. Requirements for notification Carl-Uno presented the requirements for IPP notification: Notification Requester Notification Recipient(s) Notification Content (events, attributes) Notification Formats (human, machine) Notification Timeliness (email, immediate) Scott Isaacson reported that there is an LDAP I-D in WG last call on dynamic attributes: draft-ieft-asid-ldapv3-dynamic-07.txt A requester can supply a "persistent search" on some dynamic attributes of an entry and get results whenever they change. Thus LDAP is providing a mechanism that could be used for notification. This approach scales, in that the LDAP server is centralized, so that each client that wanted to get notifications would register with the LDAP server once. Printers would indicate events to the LDAP server once for each event, no matter how many clients wanted results. Scott also presented a summary of a survey of notification mechanisms that have been developed in other arenas: message queue (pull) publish/subscribe (push) Quality of Service (privacy, latency, authentication, authorization) Variants (durable, once, at least once, at most once) Industry (OMG, Java, SNMPv3, email, SMTP MDN/DSN Abstract Events: Printer (error, warning, report) Job (error, warning, report) Concrete Events: State Change (input tray < 50 sheets) Concentrate on abstract events An attendee suggested that we consider Tool Talk has broadcast has event filtering Jeff Case, SNMPv3 developer, was present and indicated that SNMPv3 needed the System Administrator to setup authorization for each subscriber. Jeff Case and Keith Moore live near each other in Tennessee and will get together to discuss SNMPv3 capabilities and usage for notification. It would be good if a PWG member could attend their discussion as well. 2. Directory Schema Scott Isaacson indicated that he and several other IPP folks worked with the SLP editor to update the printer scheme intended to cover an IPP printer and an LPD printer. The entries for each might look like: service:printer:http://server.sun.com/cgi-bin/push-printer service:printer:lpr:// The SLP STRINGL (L for literal) is identical to IPP keywords, i.e., no translation to user's natural language. One SLP entry is needed for each printer and security combination. So even if an IPP Printer uses a single URI for both secure and regular, the SLP directory will need two entries. In SLP, the concrete protocol is http and lpr, respectively, and the abstract protocol is ipp. 3. Future Work Carl-Uno indicated that possible future work might include: 1) System Administrator functions 2) Extensions, such as dictionaries and per document attributes 3) MIME media types for each of the Printer MIB Interpreter Language families that do not currently have MIME media types. 4) Extensions for Host-to-Device usage 3.1 MIME media type feedback IETF feedback indicated that we should ask vendor's whether they wanted to register their own Interpreter Language family, or wanted the PWG to do it on their behalf. Keith Moore indicated that there is no problem with the PWG registering something that a particular company owns, especially if it is in common usage but that company isn't registering the Interpreter Language family. On the other hand, if an Interpreter Language Family isn't being used any more, there is no point in registering it. ACTION ITEM (Tom Hastings): prepare a straw man list of Printer MIB Interpreter Language family entries, indicating which already have MIME media types, which the PWG wishes to register, unless the vendor responds that they prefer to, and which the PWG has no interest in registering and will leave to the vendor to do as it pleases. 3.2 Host-to-device extensions Keith Moore indicated that the IETF might be willing to have a host-to-device protocol on the IETF standards track. He'd like to hear more about it. 4. Keith Moore's questions and feedback about IPP Keith indicated that he is reading the IPP documents carefully. Because the document is long, it is taking a while. He and the IESG will have some responses in a few weeks. He has some questions that the group was glad to answer: 1) What kind of extensions can be added without effecting interoperation? Answer: new values to existing attributes, new Job Template attributes, new Operation Attributes, and any Job Template attribute extension (if the requester omits or supplies the "ipp-attribute-fidelity" = 'false'). 2) He questioned the Create-Job "ipp-attribute-fidelity" operation attribute being for all Job Template attributes at once. He thought that the *implementation code* would be simpler and more extensible if fidelity were specified per attribute. Answer: We explained that we could compatibility add a Create-Job operation attribute that explicitly listed Job Template attributes that were compulsory (and/or one that listed Job Template attributes that were non-compulsory), since unknown operation attributes SHALL be ignored and returned in the response (with 'successful-ok-ignored-or-substituted-attributes' status code returned as a status). Only if ignoring an operation attribute extension would adversely affect new clients working with older servers, would we have to increment the major version number of the protocol. This was an illustration of how we could compatibly add attributes without impacting interoperability. 3) What job state should an IPP Printer return, if it sends jobs to a device or server that cannot be queried? Answer: return the 'unknown' value for a query of the job's "job-state" attribute. 4) What were the IPP WG feelings about using the Post HTTP operation for all IPP operations? Answer: The meeting attendees discussed the issue of using Post versus a new operation. Keith indicated that using a new operation would simplify administration of firewalls. On the other hand, there were HTTP experts present that said that the purpose of a Post operation was to update a data base. The IPP create operations certainly fit that description. However, the IPP query operations (Get-Job-Attributes, Get-Printer-Attributes, Get-Jobs), aren't updating a data base. There was no conclusion for or against using HTTP Post (or a mixture of Post and Get) or a new operation. As before, there are pros and cons.