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=20
=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 =
optional
part of the protocol.=20
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 =
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.=20
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.=20
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.=20
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.
=20
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:
=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 =
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:
=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=20
=B7 status-code=20
=B7 request-id
=B7 job-printer-uri=20
=B7 job-id=20
=B7 job-trigger-events=20
=B7 job-trigger-message
=B7 job-trigger-time
=B7 job-trigger-date-time=20
=B7 job-state =20
=B7 previous-job-state
=B7 job-state-reasons=20
=B7 previous-job-state-reasons=20
=B7 subscription-id=20
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=20
=B7 status-code=20
=B7 request-id
=B7 printer-uri-supported=20
=B7 printer-trigger-events=20
=B7 printer-trigger-message
=B7 printer-trigger-time=20
=B7 printer-trigger-date-time=20
=B7 printer-state=20
=B7 previous-printer-state
=B7 printer-state-reasons
=B7 previous-printer-state-reasons =20
=B7 subscription-id=20
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):
=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 =
the
client.)
For job-related subscriptions, the lease will last for the duration of =
the
job.
=B7 Subscription lease information should be maintained (if possible) =
over 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. =
Should
the client be required to support both-and select the appropriate one? =
Or
maybe a TCP connection should always be used?=20
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:
=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 =
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.
----=20
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=20