IPP> MOD - Issue 34 - support of "multiple-document-handling" when Cre ate-Job is supported

IPP> MOD - Issue 34 - support of "multiple-document-handling" when Cre ate-Job is supported

IPP> MOD - Issue 34 - support of "multiple-document-handling" when Cre ate-Job is supported

dcarney at us.ibm.com dcarney at us.ibm.com
Tue Apr 27 16:31:59 EDT 1999

I oppose this proposal.

It seems to me that *if* there is a good use of Create-Job when not doing
multiple documents, this proposal should clearly be opposed, and I think I
have such a use.

Imagine a printer that does not support multiple documents.   Imagine we
want to monitor job status on this printer.  Imagine we are to print a 100
page job (or a 15 page job full of graphics).

If we use the Print-Job operation to submit the job for printing, we will
not, in general, receive the Print-Job response until the job has been
fully submitted.  This means we can't monitor this job until then either,
since we won't have a job-uri until then.  Depending on the memory and
processing power of our printer, it would not be uncommon that our 100 page
job had already printed 80 pages by this time.  Our "page printed" count,
then, would jump from 0 to 80 in one fell swoop.  Not very impressive
monitoring.  (And for a really graphic-intensive job, it would not be
uncommon that all but the last page will have printed before we would get
the job-uri and be able to even *begin* monitoring!)

However, using the Create-Job operation, we can get the job-uri
immediately, and start monitoring the job immediately, concurrently with
submission.  Our "pages printed" count, then, would be accurate.

Unless my understanding of the Print-Job and Create-Job operations is
flawed, I strongly believe that to do reasonable page-level monitoring, the
Print-Job operation is inadequate.

I also don't believe that forcing support of multiple documents on all
printers if they want to be able to be monitored accurately is justified,
especially since there does not seem to be any conceptual link between
"multiple documents" and "job status monitoring".

Therefore, my proposed text change is only to section 2.16 of the
Implementer's Guide for IPP/1.0.  Replace the text shown in Tom's note
below with the following:

        2.16   The "multiple-document-handling" Job Template attribute and
            of multiple document jobs
        There is a valid reason for an implementation to support
Create-Job, yet not
        support "multiple-document-handling"--namely that the ability to
        monitor the job throughout its life cycle requires Create-Job.
        implementations would signal this level of support by not
implementing the
        "multiple-document-handling-supported" attribute.  Clients MUST NOT
        send multiple Send-Document operations to such an implementation.

Dennis Carney
IBM Printing Systems Company; (303)924-0565

-----Original Message-----

"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 04/22/99 06:13:00 PM

To:   ipp <ipp at pwg.org>
cc:    (bcc: Dennis Carney/Boulder/IBM)
Subject:  IPP> MOD - Issue 34 - support of "multiple-document-handling"
      when Cre ate-Job is supported

While editing the Implementer's Guide for IPP/1.0, I found the following
issue buried in it.  Any objection to the suggested text at the end?  If I
don't hear any objections by the end of the Last Call comment period (End
April), I'll edit it into the Model and Semantics document.


          2.16 Support of multiple document jobs
          ISSUE:  IPP/1.0 is silent on which of the four effects an
implementation would perform if it supports Create-Job, but does not
          A fix to IPP/1.0 would be to require implementing all four
values of "multiple-document-handling" if Create-Job is supported at all.
Or at least 'single-document-new-sheet' and
'separate-documents-uncollated-copies'.  In any case, an implementation
supports Create-Job SHOULD also support "multiple-document-handling".
Support for all four values is RECOMMENDED, but at least the
'single-document-new-sheet' and 'separate-documents-uncollated-copies'
values, along with the "multiple-document-handling-default" indicating the
default behavior and "multiple-document-handling-supported" values.  If an
implementation spools the data, it should also support the
'separate-documents-collated-copies' value as well.

Suggested clarification:
Instead of talking about the values that MUST or SHOULD be supported, it
would be much simpler just to clarify IPP/1.1 to REQUIRE support of the
"multiple-document-handling" attribute with at least one value if the
Create-Job operation is supported.

Suggested text:
Add to section 3.2.4 Create-Job operation:
If the Printer object supports this operation, then it MUST support the
"multiple-document-handling", "multiple-document-handling-default", and
"multiple-document-handling-supported" Job Template attributes with at
one value (see section 4.2.4).  Then the client can discover what multiple
document handling is available and control it if more than one value is

Insert this sentence after the first sentence of section 4.2.4
multiple-document-handling(type 2 keyword):
This attribute MUST be supported if the Create-Job operation is supported
(see section 3.2.4).

More information about the Ipp mailing list