Tom-
I don't think your counter-proposal is going to work. As your discussion on
server-error-busy illustrates, any individual request could be rejected.
Without document-number the Printer has no way of knowing that one document
of the Job didn't make it. The client knows, but by the time it does, it
could be too late. HTTP pipelining has this same problem; you really can't
do it safely (or legally, since Send-Document is non-idempotent) because
you never know if a request somewhere in the middle of the stream is going
to fail. With document-number, the Printer has enough information to
determine whether or not it has received all documents of a Job before it
starts printing. And when a Send-Document request is rejected, the Client
can just resend the rejected request at a later time and let the Printer
figure out where it goes in the Job. With document-number, we could use
HTTP pipelining, since "user-agent software with semantic understanding of
the application" could automatically handle retries for failed requests.
I'd really like to avoid the state tracking that your proposal would
require. I'd like to allow for an architecture in which limited resources
are pooled, and waiting tasks compete for the resources as they become
available, without having to keep track of ordering. For example, suppose I
have 100 documents to send over 4 connections. I'd like to keep each
connection busy sending a document without having to worry about the
(ever-changing) states of the other 3 connections and 99 documents.
Regarding existing Printers, I don't think I would count on them doing the
right thing with documents out of order or in parallel. We should make it
a rule that if a Printer returns "document-number" as unsupported, the
client MUST send the documents synchronously. As the document-number
proposal stands now, that would mean that the client would have to have
received at least one Send-Document Response before it could safely shift
into parallel or pipeline mode. We could improve on that by making
"document-number" an operation attribute of the Create-Job operation (value
always 0 on Create-Job). Then, when the Printer gets the Create-Job
response it knows whether or not "document-number" is supported.
(Create-Job is always synchronous anyway since you need the Job target
before you can do any Send-Documents.)
-Carl
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 10/25/99 12:21:34 AM
To: Carl Kugler/Boulder/IBM at IBMUS
cc: Michael Sweet <mike at easysw.com>, ipp at pwg.org
Subject: RE: IPP> Proposal: New document-number operation attribute for Se
nd-Document [simpler counter-proposal]
Carl,
I see why I was confusing you. I wrote "client" when I meant "printer".
No
wonder you were confused. So let me try again about whether or not there
is
an issue of adding the "document-number" to the existing Send-Document and
Send-URI operation:
You wrote:
>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 Printer is just going to ignore the "document-number"
operation attribute as it is supposed to do for any operation attributes it
doesn't recognize. At least the client will know, because such a Printer
MUST return the "document-number" in the Unsupported Attributes Group. So
the client that is sending documents out of order will not get the desired
result on a Printer that doesn't support "document-number", but does allow
more that one Send-Document request to be sent in parallel.
TH> However, I have a simpler proposal that allows multiple documents to be
sent in parallel, but doesn't need the new "document-number" attribute at
all. See if you think it meets a client's requirements. Sending documents
in parallel seems a good feature. Sending them out of order seems like
overkill. Here's the proposal:
Clarify that the Printer produces the documents positionally within a job
copy in the order that the Send-Document or Send-Uri request is first
received by the Printer (not when the last data is sent by the client).
When the Printer supports parallel Send requests, the client can (with
chunking) can delay sending after the first chunk on any of the
Send-Document requests that are open in parallel. I think this allows the
client the flexibility that you seek without putting any undue burdens on
the Printer. Also it is more compatible with IPP/1.1. Finally, it
eliminates one more mis-match between clients and servers, thereby
improving
interoperability.
Finally, we have to deal with the Printer that supports multiple documents,
but doesn't allow a second Send-Document or Send-URI request before the
first one completes, which is a legitimate implementation. In such a case,
the Printer would reject the second and subsequent Send requests, until the
first one finishes. Then the client would know that the Printer didn't
support the documents in parallel feature. Perhaps we need to clarify
which
status code the IPP Printer returns in this case, probably 13.1.5.8
server-error-busy (0x0507) which reads:
A temporary error indicating that the Printer is too busy processing jobs
and/or other requests. The client SHOULD try the unmodified request again
at
some later point in time with an expectation that the temporary busy
condition will have been cleared.
Comment?
Tom
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Wednesday, October 20, 1999 08:21
To: Hastings, Tom N
Cc: Michael Sweet; ipp at pwg.org
Subject: RE: IPP> Proposal: New document-number operation attribute for
S end-Document
Tom wrote:
>-----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).
Tom, you're confusing me here. I'm talking about whether or not a client
includes "document-number" in a REQUEST. An existing client that doesn't
know
anything about "document-number" will obviously never send the
"document-number"
attribute so the IPP Object will never return it as unsupported. So I
don't
understand what you mean by an existing client ignoring "document-number".
Presumably, existing clients do the Create-Job, Send-Document,
Send-Document...
series of operations synchronously and sequentially. So the fact that they
know
nothing of "document-number" shouldn't hurt anything.
Presumably, any Printer that doesn't support "document-number" (including
existing Printers), will return any "document-number" operation attribute
supplied by a client in the Unsupported Attributes response group, but
otherwise
ignore the attribute. A client that receives "document-number" in the
Unsupported Attributes response group should not expect the Printer to be
able
resequence Documents within a Job and therefore should avoid any attempt to
parallelize or pipeline the requests. Instead, it should send the requests
synchronously, doing one Send-Document, waiting for response, doing the
next
Send-Document, etc.
>>>>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.
I agree, not sufficient justification.
>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?
Yes, sounds good to me.
-Carl
>> -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>>>>>