Subject: IPP> MOD - ISSUE - Revised discussion paper on Architecture

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 25 Feb 1997 14:42:17 PST

Architecture View of IPP

(This is a revised and narrowed down version of my earlier paper, after
discussion with Tom Hastings today, and focused on the changes that we now
suggest should be made to the model document).
  
I want us to take a step back and consider that although IPP version 1 will
have a more limited set of capabilities than DPA, we still have to pay
attention that we get a foundation on which we can expand in future versions.

I am not trying to make things more complex than they are currently planned
to be, but would like to see a better structure in how we design them.

The two areas in which I think we could do better are in defining objects,
and in selecting the right level of operations:

Objects

I strongly favor having Document as an object.

Scott has informed me that the MOD group has already accepted to define
Document as an object, although it is not yet fully reflected in the
working document, so this is not an issue any more.

Operations

I would like to see operations that are related to the IPP objects.  My
assumption is that we have three main objects in IPP version 1 - Printer,
Job, and Document.

Here are the operations that I would like to see:

· Get Printer Attributes

This would be used to find out about printer capabilities, and possibly
status, before submitting a Job. The printer capabilities could be cashed,
so this operation does not need to be made for every print request.

· Create Job

Used to initiate a new Job.  It would contain all the Job attributes needed
to validate if the job can be done (although you can still run into
problems when document data is passed later). 

The client would receive a response, confirming if the job can be done or
not (with error codes) and a job-id is returned if accepted. 

· Add Document (to Job)

This operation would be used to send one document, with its Document
Attributes, if any.  It would contain the job-id, so the Printer knows to
which Job it belongs.  Alternatively, one Document Reference could be sent,
with its Document Attributes, if any.  The server would return success or
error (with error codes). Jobs could still be turned down at this stage,
e.g. if the printer does not support the document format or if it cannot
fulfill any of the Document attributes.

· Close Job

This operation just signals to the Printer that all Documents belonging to
the Job have been sent.

· Cancel Job

Operation to delete a Job. As default, also deletes the associated
Documents.  

· Get Job Attributes

This operation is used to check up on a Job’s current attribute settings,
as well as the Job status. (May also include some Printer status
attributes, which are necessary to explain the Job status).

· Send Job Notification (probably realized on a different transfer protocol)

This operation would send success or failure notifications about the Job
from the server to the client and possibly others, such as the operator or
administrator, or an intended recipient for the Job output.  This
definition should include the minimum amount of information sent back
(which should be in machine readable format, and optionally in human
readable form).

· Send Printer Notification (probably realized on a different transfer
protocol)

This is intended to signal problems with the Printer (may be due to
problems on the device).  It can be sent to the operator (or the end-user
if there is no dedicated operator). This definition should include the
minimum amount of information sent back (which should be in machine
readable format, and optionally in human readable form).

An assumption is still that several "model" operations, can be combined
when we map them to a particular transfer protocol such as HTTP 1.1.  For
example, the operations Create Job, Add Document, and Close Job could be
combined in cases where one small document is to be sent.  At the same
time, these operations could be mapped to separate transfer operations for
bigger documents or multiple document cases.

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: [email-masked]