IETF45 - IPP WG Session - July 14, 1999 The meeting was attended by a little more than 20 people, many of which came from the Internet Fax WG. Lee Farrell was the note taker. Carl-Uno Manros led the meeting and provided the agenda: Update on project status Remaining work within the current charter IPP Notifications IPP Implementer's Guide for IPP/1.1 IPP WG Charter update Possible future work on IPP IPP Notifications Carl-Uno briefly referenced the IPP Notification activity: Notification requirements for IPP Notification solutions for IPP in progress - no Internet-Draft yet He gave a description of the Notification Requirements "Overall Model" (see diagram below.) He pointed out that IPP Notifications would be an optional part of the protocol. Legend: A = Client and Notification Recipient B = Notification Recipient (subscription by some third party) O A +----------+ Create Request with ########### /|\ | client/ |----Subscriptions------------># IPP # / \ | notif. | # Printer # end- | recip. |<---Job and Printer ----------# Object # user +----------+ Notifications ########### / O B +----------+ / /|\ | notif. | / / \ | recip. |<---Job and Printer -------+ end- | | Notifications user +----------+ He then provided a few scenarios that illustrate the uses of IPP Notification, and serve as the basis for various requirements. Scenario 1 I am sitting in my office and submit a print job to the printer down the hall. I am in the same security domain as the printer and geographically near. I want to know immediately when my print job is completed (or if there is a problem) because the document I am working on is urgent. Scenario 2 I am working from home and submit a print job to the same printer as in the previous example. However, since I am not at work, I cannot physically get the print file or do anything with it. It can wait until I get to work this afternoon. However, I'd like my secretary to pick up the output and put it on my desk so it doesn't get lost or miss-filed. I'd also like a queued notification sent to my email so that when I get to work I can tell if there was a problem with the print job. Scenario 3 I am sitting in my office and submit a print job to a client at an engineering firm we work with on a daily basis. The engineering form is in Belgium. I would like my client to know when the print job is complete, so that she can pick it up from the printer in her building. It is important that she review it right away and get her comments back to me. Carl-Uno mentioned that the notification should be available in two different formats - one for machine consumption, and one for "human readable." Scenario 4 I am in a hotel room and send a print job to a Kinko's store in the town I am working in, in order to get a printed report for the meeting I am attending in the morning. Since I'm going out to dinner after I submit this job, an immediate notification won't do me much good. However, I'd like to check in the morning before I drive to the Kinko's store to see if the file has been printed. An email notification is sufficient for this purpose. Scenario 5 I am printing a large, complex print file. I want to have some immediate feedback on the progress of the print job as it prints. Scenario 6 I am an operator and my duties is to keep the printer running. I subscribe independently from a job submission so that my subscription outlasts any particular job. Scenario 7 I am an printer statistics application. I subscribe independently from a job submission so that my subscription outlasts any particular job. My subscription may persist across power cycles. There is still much debate regarding scenario 7. Many people in the group are concerned about any scenario that might imply support for accounting capabilities. The requirements for such support would be much more difficult for guaranteeing the necessary reliability (and security?) required for accounting applications. Some people think it is desirable. There are two variations of the Notification Subscription: As part of IPP Job Submission (for single Job) As independent Operation (for Printer and all Jobs) Also, there are two possible formats for the Notification: Machine friendly: application/ipp MIME format Human readable: text format (e.g. email) Bob Herriot pointed out that an additional subscription capability is being considered. It would be possible to specify an individual job, and receive notifications only related to that job. Additional items that still need consideration and further discussion: Notification transport: Simple UDP, without confirmation Email, with or without confirmation Other, such as HTTP Other notification criteria: Reliability Delay, frequency, repeatability Security Carl-Uno provided a list of the Job Notification content items: version-number status-code request-id job-printer-uri job-id job-trigger-events job-trigger-message job-trigger-time job-trigger-date-time job-state previous-job-state job-state-reasons previous-job-state-reasons subscription-id The concept of using "multi-part alternative" as a possible format was raised. This will be investigated further. He also provided a list of the Printer Notification content items: version-number status-code request-id printer-uri-supported printer-trigger-events printer-trigger-message printer-trigger-time printer-trigger-date-time printer-state previous-printer-state printer-state-reasons previous-printer-state-reasons subscription-id Carl-Uno asked the group if anyone had any opinions about whether or not the group should attempt to support accounting requirements. One opinion was expressed: "I think the whole idea of push-based accounting is a bit weird." Keith Moore stressed that whatever choice was made, he wants it to be optional. He later advised that the group should first concentrate on "the lightweight version" of collecting statistics, rather than attempting full support for a reliable accounting system. Bob Herriot provided some conclusions and issues that were discussed at the previous IPP meeting (held in Copenhagen a week earlier): Sequence ids will be added to notifications When processing gets "busy", notification service may degrade; IPP will not allow the client to request "high quality service" The concept of subscription "leases" will be used. The server will decide the length of a lease (less than or equal to the period requested by the client.) For job-related subscriptions, the lease will last for the duration of the job. Subscription lease information should be maintained (if possible) over a power recycle Duplicate subscriptions will be allowed. A Printer might suppress duplicate notifications. There was a long discussion about using UDP-based protocols that don't have congestion control. Generally speaking, this is undesirable - but it is only meaningful for communication of "lots of data". For "per page" event notification, it is suggested that TCP connections should be used. Should the client be required to support both-and select the appropriate one? Or maybe a TCP connection should always be used? It was noted that the Fax community "really likes" reliable page-based notification. There is a desire to know, for example, that out of 50 pages sent, only 49 were completed. Will an environment that can accept print jobs be so asymmetric that notifications might get lost? Is the entire issue of "real-time vs. reliability" truly an appropriate concern for this situation? One person suggested that TCP should be implemented first-and only after reasonable experience is gained should the question of using UDP be revisited. Charter Updates Carl-Uno noted that the Charter contents are in serious need of update. The following items were identified: Finalization of IPP/1.1 documents on: Model and Semantics Encoding and Transport Nov 1999 IPP/1.1 Implementer's Guide Oct 1999 Requirements for IPP Notifications Oct 1999 IPP Notifications Specification Q1 2000 Wrap up Current Charter Q2 2000 Future Work A few items have already been identified for "next phase" IPP activity: Additional Operations for Administration Additional Features for Production Printing Carl-Uno has asked Keith Moore for advice on whether the above topics should be pursued outside of the IETF or under a re-chartered (new?) Working Group activity. Unfortunately, Keith had left the meeting before he could respond. Meeting adjourned.