You state:
"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."
Your proposed solution makes an assumption that a client can control the
order that a printer receives two requests when the client sends the 2nd one
before getting a response from the printer on the first. Using chunking is
not sufficient because it is at the HTTP layer and not at the TCP layer. The
lower levels of the client's API know whether a connnection has been made
with the printer, but at the HTTP POST level, the client doesn't know until
it receives a response.
Bob Herriot
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Sunday, October 24, 1999 11:22 PM
To: kugler@us.ibm.com
Cc: Michael Sweet; ipp@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@us.ibm.com [mailto:kugler@us.ibm.com]
Sent: Wednesday, October 20, 1999 08:21
To: Hastings, Tom N
Cc: Michael Sweet; ipp@pwg.org
Subject: RE: IPP> Proposal: New document-number operation attribute for
S end-Document
Tom wrote:
>-----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
>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@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
>>Send-Document
>>
>>
>>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
>>
>>
>