IPP> Proposal: New document-number operation attribute for Send-Document

IPP> Proposal: New document-number operation attribute for Send-Document

IPP> Proposal: New document-number operation attribute for Send-Document

kugler at us.ibm.com kugler at us.ibm.com
Tue Oct 19 19:35:32 EDT 1999


>Carl and Michael,
>I assume that this new OPTIONAL "document-number (1:MAX)" operation
>attribute is for use by the client in requests.  If supplied, then it is
>order that the client wants the documents to be printed, correct?

Yes.  It should start at 1 and increase to the total number of documents (when
last-document=true).  No holes or duplicates.

>Can the client supply the numbers out of order, i.e., submit document 3,
>followed by document 1, followed by document 2?  What burden does that put
>on IPP Printers to accept documents in a different time order than they are
>going to be printed?  Or MUST the client supply the numbers in
>increasing order, except when submitting more than one document in

I think that if you allow parallel Send-Documents, then getting them out of
order sequentially is just a special case.  So I would say yes, a client can
supply the documents out of order.  A Printer that doesn't want to accept this
burden could reject the "document-number" operation attribute as unsupported.
This puts the burden back on the client to serialize the transmission of the

>But it would also be useful to make "document-number (1:MAX)" an OPTIONAL
>operation attribute that the IPP Printer could return in responses, whether
>the client had supplied it or not.  (We had the same output-only attribute
>in ISO DPA, called "document-sequence-number").
>What do you think?

Hmm... I have no objection, but what's it used for?


>-----Original Message-----
>From: Michael Sweet [mailto:mike at easysw.com]
>Sent: Thursday, October 14, 1999 06:03
>To: kugler at us.ibm.com
>Cc: ipp at pwg.org
>Subject: Re: IPP> Proposal: New document-number operation attribute for
>kugler at us.ibm.com wrote:
>> ...
>> to send multiple documents in parallel.  On the Printer side, a
>> multi-threaded implementation, capable of processing multiple
>> operations in parallel, may be more efficient than a single-threaded
>Actually, it doesn't even need to be multi-threaded to handle multiple
>connections; a state machine server (like CUPS) can do it, too.
>> ...
>> To solve this problem, we propose a new operation attribute for the
>> Send-Document (and, by extension, Send-URI)  operations.
>> Specifically, Integer (1..MAX) "document-number" .  This is a
>> document sequence number that begins with '1' for the first
>> document, and is incremented by one for each subsequent document up
>> to and including the document with "last-document"='true'.  Thus,
>> when the Printer|Job gets the final document (last-document=true),
>> it can examine the document-numbers of the documents previously
>> received to a) ensure that all have been received, b) determine the
>> proper ordering of the documents within the Job.
>We've actually been looking at this problem for our next
>implementation of CUPS, and it looks like your approach will
>definitely solve it elegantly.
>Michael Sweet, Easy Software Products                  mike at easysw.com
>Printing Software for UNIX                       http://www.easysw.com

More information about the Ipp mailing list