IPP Mail Archive: RE: IPP> Proposal: New document-number operation attribute for S

IPP Mail Archive: RE: IPP> Proposal: New document-number operation attribute for S

RE: IPP> Proposal: New document-number operation attribute for S

Hastings, Tom N (hastings@cp10.es.xerox.com)
Tue, 19 Oct 1999 19:25:49 -0700

-----Original Message-----
From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
Sent: Tuesday, October 19, 1999 16:36
To: Hastings, Tom N
Cc: Michael Sweet; ipp@pwg.org
Subject: RE: IPP> Proposal: New document-number operation attribute for


>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?


>-----Original Message-----
>From: Michael Sweet [mailto:mike@easysw.com]
>Sent: Thursday, October 14, 1999 06:03
>To: kugler@us.ibm.com
>Cc: ipp@pwg.org
>Subject: Re: IPP> Proposal: New document-number operation attribute for
>kugler@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@easysw.com
>Printing Software for UNIX http://www.easysw.com