IPP> Minutes for 01/15/97 Conference Call

IPP> Minutes for 01/15/97 Conference Call

IPP> Minutes for 01/15/97 Conference Call

Jim Walker walker at dazel.com
Thu Jan 16 17:26:15 EST 1997

This is a multi-part message in MIME format.

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.


Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

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.


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


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?


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.


More information about the Ipp mailing list