This is a multi-part message in MIME format.
--------------452C6E3F57
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The attached is the text version of my minutes from the IPP conference
call on January 15, 1997. Corrections are welcome (as are volunteers
for another secretary for the next call ;-).
I have (conveniently) lost the FTP server password, so I will send the
Word document to JK Martin under separate cover, to be posted on the
FTP server.
later...
...walker
--
Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX
--------------452C6E3F57
Content-Type: text/plain; charset=iso-8859-1; name="970115-ipp-conference-call.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="970115-ipp-conference-call.txt"
Internet Printing Project
Conference Call - January 15, 1997
The meeting was called to order at 3:00 PM CST.
Attendees:
----------
Robert Chancellor(?) - Adobe
Mabry Dozier - QMS
Bob Herriott - Sun
Dave Kellerman - Northlake Software
Carl-Uno Manros - Xerox
Jay Martin - Underscore
Randy Turner - Sharp
Bill Wagner - DPI
Jim Walker - Dazel
Agenda:
-------
o OMG coordination
o Requirements/Scenarios
o April meeting
OMG coordination
----------------
Carl-Uno was calling in from Florida, where he and others were meeting
with the OMG to discuss the OMG Print Facility. There are two
submissions in response to the RFP, one from Xerox/Novell (and others?),
and one from Ricoh. Apparently, the two parties have agreed to
coordinate a single submission that would be aligned with the IPP.
Unfortunately, there are timing constraints, as the final OMG submission
is due in April. Perhaps we will have the next version of the IPP draft
by then?
Requirements/Scenarios
----------------------
There were more issues raised than resolved! The topics discussed were:
o Encoding and transport
Carl-Uno raised the issue again of transport and encoding. There were
still negative comments from Albuquerque regarding MIME encoding, so
that still seems to be an open issue. As for transport, the options
seem to be HTTP 1.1, (a yet-to-be-defined) HTTP-lite, and our own IPP
protocol over TCP/IP. No decisions were made, although the group seemed
to express that we should require very little on the client side.
Perhaps just a web browser? How little is that really?
There was also the question raised again about whether we should
consider HTML on top of HTTP, using standard tags for different fields.
Carl-Uno was concerned about being able to send a document, but Bob
Herriot pointed out that there is an RFC for form-based file upload
using HTML forms.
o Microsoft NT 5.0 printing influence
Carl-Uno asked if there was any input on the Microsoft/HP/Lexmark print
overview given at Albuquerque by Don Wright. We felt that it is
probably too early to evaluate this technology, but will be interested
in finding out more at the February meeting in San Jose. n Printer
fan-in and fan-out
Jim Walker raised the issue of whether we should explicitly support
printer fan-in by having (at least) a 2-level printer model (akin to
the logical/physical printer model in the DPA and POSIX 1387.4). Bob
Herriot reiterated the decision from the Model subgroup meeting in
Albuquerque; effectively that group decided that, although the feature
may be needed in IPP V2 (to simplify the administration model), it was
not needed for the end-user operations to be specified in IPP V1. This
still seems to be an issue.
Bob Herriot discussed his dissatisfaction with the result of the
discussion on printer-state in a fan-out model. He felt that there
should be an indication of the "throughput" associated with the
printer object (for example, if there are 5 output devices associated
with an IPP printer object, and 2 of them are not printing because of
operator/administrator issues, then the relative throughput of the IPP
printer is 3/5, or 60%).
More discussion regarding the fact that we already have a multi-level
printer model (because we have the associated-output-devices attribute
in the IPP printer object).
o Operator versus end-user notification
There was discussion regarding the roles of the user and operator, and
when they would receive notification of problems. Carl-Uno suggested
that the "user wants to know if there is anything keeping their job
from printing", and that might mean different things depending on the
state of a job (the owner of a job that is pending at an IPP printer
that supports multiple output devices might want to know when any of
those output devices has a problem, but once that job is processing at
an output device, they would only care about that one output device).
There might be different indications; e.g.,
job is pending (queued)
job is pending, and there is reduced (or no) throughput at the
associated output devices
job is pending, and there is no associated output device capable
of printing that job
job is processing, and assigned output device needs attention
o Printer object characteristics
There was discussion regarding the relation of the IPP printer object
and the Printer MIB. It was suggested that the IPP printer object
would reuse a subset of the Printer MIB objects. In addition, an IPP
server might query the Printer MIB in an associated output device in
order to fill in the printer object attributes.
A related discussion also questioned whether the associated output
devices would/could be queried using the IPP protocol. Someone
(Carl-Uno?) suggested that any information presented to the user would
come from the IPP printer object, not from the associated output
device(s). This still remains open.
o Single print job to multiple output devices
Carl-Uno asked if we should consider the scenario of a single print
job split up among multiple output devices. Someone (Bill Wagner?)
mentioned that the JMP explicitly excluded this option. We decided to
follow the lead of the JMP, and not try to accommodate this scenario.
o Security aspects of pull model
Carl-Uno raised several issues regarding the security of the pull
model (i.e., the case of a print job containing the URL reference to a
document, rather than the document contents). For example, the server
might have to retain the user’s credentials in order to retrieve
the document.
April meeting
-------------
Several people asked for clarification of the April meetings. Carl-Uno
will check with the IETF area directors to see when the IPP working
group meeting were to be scheduled to see if we could schedule an
additional full-day meeting for the IPP (outside of the IETF meetings).
Others of us felt that the meeting schedule should just remain as it is.
This issue remains open.
The meeting ended at 5:00 PM CST.
--------------452C6E3F57--