>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
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
burden could reject the "document-number" operation attribute as
This puts the burden back on the client to serialize the transmission of the
TH> Well, an existing client is just going to ignore the "document-number"
operation attribute as it is supposed to do for any operation attributes it
doesn't recognize. Though perhaps, an IPP Printer might reject a second
Send-Document when another Send-Document is already in progress but hasn't
completed yet. Perhaps we need to clarify which status code the IPP Printer
returns in this case (or add a new status code).
>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?
TH> What happens if a client submits multiple documents in parallel and
doesn't supply the new "document-number" attribute. This response
"document-number" would indicate the order that each was going to be
printed. But perhaps that isn't sufficient justification to have the
document-number come back in the response. Perhaps, instead, we REQUIRE the
client to supply the new "document-number" operation attribute if it submits
a Send-Document before completing a previous Send-Document?
>From: Michael Sweet [mailto:firstname.lastname@example.org]
>Sent: Thursday, October 14, 1999 06:03
>Subject: Re: IPP> Proposal: New document-number operation attribute for
>> 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 email@example.com
>Printing Software for UNIX http://www.easysw.com