1. The scenarios are very good and helpful in visualizing the requireme=
nts.
2. I really like Keith Moore's suggestion to "...first concentrate on t=
he
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=
y such
that
a. If you drop a few you can always "catch up"... after all... it's ju=
st a
progress
indicator. How many times has your web browser given you misleadi=
ng
"progress" (14 sec remaining for the last 2 minutes) yet you'd ra=
ther
have this than no progress at all
b. There are multiple opportunities to deliver the notification "paylo=
ad".
Thus, information IN the payload that might be crucial to identif=
ying
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=
is one.
> Duplicate subscriptions will be allowed. A Printer might suppress
>duplicate notifications.
4. Future Work.
Previously, we had discussed the notion of extending IPP for tighte=
r control
of the
Server to Device printing relationship. We already have part of the=
story
(printer
attributes, job status). Notifications were a key missing part. Res=
ources
could
be another. The Server to Device extensions should also be consider=
ed as
potential future work.
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
"Manros, Carl-Uno B" <cmanros@cp10.es.xerox.com> on 08/02/99 11:29:11 A=
M
To: IETF-IPP <ipp@pwg.org>
cc: "Moore, Keith" <moore@cs.utk.edu>, "F=E4ltstr=F6m, Patrik" <paf@s=
wip.net>
Subject: IPP> ADM - Meeting Minutes from IETF45 - IPP WG Session - Jul=
y 14, 199
9 in Oslo
=
IETF45 - IPP WG Session - July 14, 1999
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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:
=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
IPP Notifications
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" =
(see
diagram below.) He pointed out that IPP Notifications would be an optio=
nal
part of the protocol.
Legend:
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
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 th=
e
hall. I am in the same security domain as the printer and geographicall=
y
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 import=
ant
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 tow=
n 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 immediat=
e
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 subsc=
ribe
independently from a job submission so that my subscription outlasts an=
y
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 gro=
up
are concerned about any scenario that might imply support for accountin=
g
capabilities. The requirements for such support would be much more diff=
icult
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=
eing
considered. It would be possible to specify an individual job, and rece=
ive
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:
* Reliability
* Delay, frequency, repeatability
* Security
Carl-Uno provided a list of the Job Notification content items:
=B7 version-number
=B7 status-code
=B7 request-id
=B7 job-printer-uri
=B7 job-id
=B7 job-trigger-events
=B7 job-trigger-message
=B7 job-trigger-time
=B7 job-trigger-date-time
=B7 job-state
=B7 previous-job-state
=B7 job-state-reasons
=B7 previous-job-state-reasons
=B7 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:
=B7 version-number
=B7 status-code
=B7 request-id
=B7 printer-uri-supported
=B7 printer-trigger-events
=B7 printer-trigger-message
=B7 printer-trigger-time
=B7 printer-trigger-date-time
=B7 printer-state
=B7 previous-printer-state
=B7 printer-state-reasons
=B7 previous-printer-state-reasons
=B7 subscription-id
Carl-Uno asked the group if anyone had any opinions about whether or no=
t the
group should attempt to support accounting requirements. One opinion wa=
s
expressed: "I think the whole idea of push-based accounting is a bit we=
ird."
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 f=
ull
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):
=B7 Sequence ids will be added to notifications
=B7 When processing gets "busy", notification service may degrade; IPP =
will
not allow the client to request "high quality service"
=B7 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 th=
e
client.)
For job-related subscriptions, the lease will last for the duration of =
the
job.
=B7 Subscription lease information should be maintained (if possible) o=
ver a
power recycle
=B7 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. Shou=
ld
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 pa=
ges
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=
r
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:
=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
Future Work
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=
hould
be pursued outside of the IETF or under a re-chartered (new?) Working G=
roup
activity. Unfortunately, Keith had left the meeting before he could res=
pond.
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@cp10.es.xerox.com
=