Minutes from PWG IPP Phone Conference 980429
=============================================
Notes taken by Lee Farrell
The attendees included :
Roger deBry IBM
Lee Farrell Canon Information Systems
Tom Hastings Xerox
Scott Isaacson Novell
Harry Lewis IBM
Carl-Uno Manros* Xerox
Paul Moore Microsoft
Kris Schoff Hewlett Packard
Peter Zehler Xerox
* IPP Chairman
Carl-Uno Manros led the meeting. His agenda topics were:
"Main agenda point is to discuss the revised IPP Notifications proposal
from Harry Lewis and Tom Hastings. I hope that we can get this out as an
Internet-Draft after our review in the conference."
"We may also want to spend some time on the discussion about reaching
MIB information over IPP. As usual, I think some initial agreements
about scope and requirements would be useful."
Notifications for the IPP Print Protocol --
The group discussed the proposal that was issued last week by Harry
Lewis and Tom Hastings
[ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf]
Tom provided a brief overview of the proposal.
Paul Moore had several questions. He also pointed out that the document
doesn't define the meaning of "Notification."
Why have both human readable as well as machine readable formats?
To avoid attempts to parse the human readable. The recipient can ignore
the parts it doesn't understand.
Who responds to the notification request?
The IPP printer.
There is no model where the IPP client sends the notification?
Correct.
I envisage a user wanting to be notified by e-mail, but the
(inexpensive) printer doesn't support e-mail.
Yes, but a server could handle this notification (by polling, for
example) on behalf of the printer. This could be an issue for the SDP
discussions.
But this means that the server must "crack open" the packet being sent
to the printer.
Yes, but this is probably easier than a full mapping to some other
protocol.
Several other discussion points and questions were also raised --
Harry explained that the proposal attempts to address both IPP and SDP
issues.
Perhaps we should allow the client to specify if it wants either machine
readable or human readable or both?
Is it true that IPP "client-to-server" will need only human readable
while IPP "server-to-device" will need machine readable? Not
necessarily. The client might want to localize the received notification
for display to the user.
What if the printer sends the notification to the IPP client, and then
the client translates to display for the user? This could remove the
need for human readable form.
We need to caution against having a one-to-one correspondence between
each end-user feature and a related protocol structure.
General caution: There is no "IPP Server" defined in the model. We
should be very careful when we use this term.
There should be more notification "flavors" than just specifying that a
user wants to be notified at a given e-mail address.
Perhaps (for clarification purposes) we should call human readable forms
"messages" and machine readable forms "notifications." Their usage is
sufficiently different that we should avoid giving them the same name. A
"message" would refer to the high-level intent expressed by the user,
and a "notification" would refer to the machine readable (and
processable) form of the detailed event.
Such a separation of "messages" and "notifications" might result in
implementations trying to parse the human readable form. We would really
like to avoid this if possible.
Issue Review --
Several issues that were listed in Tom Hasting's e-mail on April 29 were
reviewed and discussed. The conclusions for each item are given below:
Issue a (lines 89-91): Should we keep the ability for the System
Administrator to define default notification, if the client does not
supply any?
---> Let's remove the defaulting altogether (and the associated
attributes.)
Issue b (lines 130-136): Are we making the recipients job more difficult
on a problem notification by sending the job-id of the job that had the
problem, rather than the job-id of the job the requested the
notification?
---> Perhaps if the submitting client is interested in printer events
(and related problems that could affect the print job progress), it
should subscribe for notifications at that level, not just the (the
user's) print job level? For all print jobs in the system that have
subscribed to the printer problem event group, they will be notified.
However, when the job is removed from the queue, the subscription will
be terminated.
[The above discussion raised a separate issue: What about subscribing
for printer problems even when there is no active print job? This was
considered "out-of-band" for IPP, and deferred for later discussion.
Perhaps a new operation for requesting notification subscription
services should be defined? This will probably require an "unsubscribe"
operation as well. To properly address this issue, a review and update
of the requirements may be necessary.]
Issue c (lines 130-136): Is there a security problem with sending the
job-id of a job that does not belong to the user that submitted the job
to the designated notification recipient? We already allow the security
policy to prevent a user from seeing any other jobs.
---> We should leave this up to the implementation. It will decide the
security policy regarding how much information is provided about other
jobs.
Issue 1 (line 210): Ok to have combined these two events into one event
(and one event group) for simplicity and specified that the notification
content is the same for all notification recipients receiving this
event?
---> See issue b discussion above.
Issue 2 (line 223): Should we register a "job-deadline-to-start" Job
Template attribute for use with IPP/1.0?
---> No. Let's remove it.
Issues d through g were deferred for later discussion.
Issue h (lines 353-378): Need to clarify that the validation is
independent of the value of ipp-attribute-fidelity, like all Operation
attributes, and unsupported values are ignored, rather than rejecting
the request.
---> Agreed.
Issue 3 (line 404 and Table 1): Do we need/want to add the missing
attributes to IPP as Printer object attributes that are indicated as "-"
in the IPP attribute column to align with the Job Monitoring MIB?
---> No, do it for later version.
Issue 4 (line 433): Should we change the name that is reserved in the
IPP/1.0: Protocol Specification from 'dictionary' to 'collection' before
the RFC is published?
---> Yes.
Sending MIB data over IPP --
The group reviewed Scott's Version 0.02 document on "IPP Sub-Unit
Objects"
[ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-sub-units-980407.pdf]
What about printers that do not have MIBs? Scott says there is no
requirement to have an SNMP agent in the printer. The proposal only
discusses a mapping that is based on the Printer MIB.
Should we incorporate the "uninteresting part" of the OID? Probably not.
If any part of the OID is used, it should be limited to the part that
doesn't change.
The Finisher MIB is part of the Printer MIB. The Job MIB is separate.
Perhaps we should add some of the desired content of the Job MIB to the
IPP Job attributes?
If there is an overlap between the Job attributes and the Job MIB, what
should be done if the values are different? We should define the overlap
to be identical, using the OID as an alias. However, Scott pointed out
that "Printer_State" is (intentionally) different between the two. Any
similar overlapping differences are probably minimal, and should be
explicitly referenced and explained for interpretation.
Carl-Uno asked if we have sufficient support for Scott's proposal.
Everyone agreed that there is support for pursuing this concept further.
There was one concern that we are taking "the obvious and easy way out"
-- often the good solutions are the painful ones. However, no one had a
better solution to propose.
The discussion of how to "stringify" the OIDs will continue on the
e-mail list.
IPP Documents --
Carl-Uno and other IPP members continue to ask the IETF Area Director
for a response on the IPP document drafts. However, there seems to be no
tangible progress. Next week it will be three months since the documents
were first submitted.
Meeting adjourned.
Next IPP Teleconference --
The next teleconference will be held on May 6 at 10:00am PST.
For next week's teleconference, we will discuss the SDP proposal
generated by Roger deBry [ftp://pwg.org/pub/pwg/sdp/sdp-proposal.pdf]
+++
Regards,
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - 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