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 <draft-ietf-ipp-not-02.txt>
· 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.
----
Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com