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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Oct 19 22:25:49 EDT 1999



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




Tom-

>
>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
>the
>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
>monotonically
>increasing order, except when submitting more than one document in
>parallel?

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
documents.

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?  

     -Carl

>
>Tom
>
>
>-----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
>Send-Document
>
>
>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