1. The scenarios are very good and helpful in visualizing the requireme=
2. I really like Keith Moore's suggestion to "...first concentrate on t=
lightweight version... rather than attempting full
support for a reliable accounting system.
3. I disagree with the (evidently) prevailing perspective regarding UDP=
> For "per page" event notification, it is suggested that
>TCP connections should be used.
The bad thing about per page notification is there are so many of them.=
The nice thing about per page notification is there are so many of them=
The multiplicity of per page notifications provides a natural redundanc=
a. If you drop a few you can always "catch up"... after all... it's ju=
indicator. How many times has your web browser given you misleadi=
"progress" (14 sec remaining for the last 2 minutes) yet you'd ra=
have this than no progress at all
b. There are multiple opportunities to deliver the notification "paylo=
Thus, information IN the payload that might be crucial to identif=
the job, user, etc... is insured by redundancy rather than by
session and packet guarantee.
c. These are small payloads. If congestion gets so bad that redundancy=
is failing... we're probably not doing much printing, either.
3. What is the rationale behind duplicate subscriptions? I've missed th=
> Duplicate subscriptions will be allowed. A Printer might suppress
4. Future Work.
Previously, we had discussed the notion of extending IPP for tighte=
Server to Device printing relationship. We already have part of the=
attributes, job status). Notifications were a key missing part. Res=
be another. The Server to Device extensions should also be consider=
potential future work.
IBM Printing Systems
"Manros, Carl-Uno B" <firstname.lastname@example.org> on 08/02/99 11:29:11 A=
To: IETF-IPP <email@example.com>
cc: "Moore, Keith" <firstname.lastname@example.org>, "F=E4ltstr=F6m, Patrik" <paf@s=
Subject: IPP> ADM - Meeting Minutes from IETF45 - IPP WG Session - Jul=
y 14, 199
9 in Oslo
IETF45 - IPP WG Session - July 14, 1999
The meeting was attended by a little more than 20 people, many of which=
from the Internet Fax WG.
Lee Farrell was the note taker.
Carl-Uno Manros led the meeting and provided the agenda:
=B7 Update on project status
=B7 Remaining work within the current charter
* IPP Notifications
* IPP Implementer's Guide for IPP/1.1
=B7 IPP WG Charter update
=B7 Possible future work on IPP
Carl-Uno briefly referenced the IPP Notification activity:
=B7 Notification requirements for IPP <draft-ietf-ipp-not-02.txt>
=B7 Notification solutions for IPP in progress - no Internet-Draft yet
He gave a description of the Notification Requirements "Overall Model" =
diagram below.) He pointed out that IPP Notifications would be an optio=
part of the protocol.
A =3D Client and Notification Recipient
B =3D 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
He then provided a few scenarios that illustrate the uses of IPP
Notification, and serve as the basis for various requirements.
I am sitting in my office and submit a print job to the printer down th=
hall. I am in the same security domain as the printer and geographicall=
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.
I am working from home and submit a print job to the same printer as in=
previous example. However, since I am not at work, I cannot physically =
the print file or do anything with it. It can wait until I get to work =
afternoon. However, I'd like my secretary to pick up the output and put=
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 =
was a problem with the print job.
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=
Belgium. I would like my client to know when the print job is complete,=
that she can pick it up from the printer in her building. It is import=
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
I am in a hotel room and send a print job to a Kinko's store in the tow=
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=
job, an immediate notification won't do me much good. However, I'd like=
check in the morning before I drive to the Kinko's store to see if the =
has been printed. An email notification is sufficient for this purpose.=
I am printing a large, complex print file. I want to have some immediat=
feedback on the progress of the print job as it prints.
I am an operator and my duties is to keep the printer running. I subsc=
independently from a job submission so that my subscription outlasts an=
I am an printer statistics application. I subscribe independently from =
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 gro=
are concerned about any scenario that might imply support for accountin=
capabilities. The requirements for such support would be much more diff=
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:
=B7 As part of IPP Job Submission (for single Job)
=B7 As independent Operation (for Printer and all Jobs)
Also, there are two possible formats for the Notification:
=B7 Machine friendly: application/ipp MIME format
=B7 Human readable: text format (e.g. email)
Bob Herriot pointed out that an additional subscription capability is b=
considered. It would be possible to specify an individual job, and rece=
notifications only related to that job.
Additional items that still need consideration and further discussion:
=B7 Notification transport:
* Simple UDP, without confirmation
* Email, with or without confirmation
* Other, such as HTTP
=B7 Other notification criteria:
* Delay, frequency, repeatability
Carl-Uno provided a list of the Job Notification content items:
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:
Carl-Uno asked the group if anyone had any opinions about whether or no=
group should attempt to support accounting requirements. One opinion wa=
expressed: "I think the whole idea of push-based accounting is a bit we=
Keith Moore stressed that whatever choice was made, he wants it to be
optional. He later advised that the group should first concentrate on "=
lightweight version" of collecting statistics, rather than attempting f=
support for a reliable accounting system.
Bob Herriot provided some conclusions and issues that were discussed at=
previous IPP meeting (held in Copenhagen a week earlier):
=B7 Sequence ids will be added to notifications
=B7 When processing gets "busy", notification service may degrade; IPP =
not allow the client to request "high quality service"
=B7 The concept of subscription "leases" will be used. The server will =
the length of a lease (less than or equal to the period requested by th=
For job-related subscriptions, the lease will last for the duration of =
=B7 Subscription lease information should be maintained (if possible) o=
=B7 Duplicate subscriptions will be allowed. A Printer might suppress
There was a long discussion about using UDP-based protocols that don't =
congestion control. Generally speaking, this is undesirable - but it is=
meaningful for communication of "lots of data". For "per page" event
notification, it is suggested that TCP connections should be used. Shou=
the client be required to support both-and select the appropriate one? =
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 pa=
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 afte=
reasonable experience is gained should the question of using UDP be
Carl-Uno noted that the Charter contents are in serious need of update.=
following items were identified:
=B7 Finalization of IPP/1.1 documents on:
* Model and Semantics
* Encoding and Transport Nov 1999
=B7 IPP/1.1 Implementer's Guide Oct 1999
=B7 Requirements for IPP Notifications Oct 1999
=B7 IPP Notifications Specification Q1 2000
=B7 Wrap up Current Charter Q2 2000
A few items have already been identified for "next phase" IPP activity:=
=B7 Additional Operations for Administration
=B7 Additional Features for Production Printing
Carl-Uno has asked Keith Moore for advice on whether the above topics s=
be pursued outside of the IETF or under a re-chartered (new?) Working G=
activity. Unfortunately, Keith had left the meeting before he could res=
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