Dennis wrote:
> I'm a bit confused: I had the (apparently flawed) impression that the plan
> was to deprecate, for a client, using the "last-document" operation
> attribute entirely--that is, say the "correct" way to say a job was done
> was to do Close-Job.
I could have gotten the notes wrong here, but I had scribbled the comment
under the Send-URI where it discussed the empty Send-Document operation to
close a job.
I see no objection to a client saving a trip and closing the job on the
Send-Document or Send-URI operation when sending actual data with the
"last-document" = 'true'.
So I think we should keep "last-document" operation for all of the following
reasons:
1. We need a "last-document" Document Description attribute for the Document
object anyway for querying, so that the client knows when its gotten to the
last Document.
2. Being able to submit data and "last-document" = 'true" saves a round trip
when creating a multiple document job.
3. The current [rfc2911] REQUIRED behaviour is the client MUST always supply
the "last-document" with a 'false' or a 'true' value in Send-Document and
Send-URI; the client MUST NOT omit the "last-document', so we'd be
deprecating something that we REQUIRE the client to supply.
4. The current [RFC2911] requirement for the Printer is:
"If the Printer supports this [Send-Document] operation but does not support
multiple documents per job, the Printer MUST reject subsequent Send-Document
operations supplied with data and return the
'server-error-multiple-document-jobs-not-supported'. However, the Printer
MUST accept the first document with a 'true' or 'false' value for the
"last-document" operation attribute (see below), so that clients MAY always
submit one document jobs with a 'false' value for "last-document" in the
first Send-Document and a 'true' for "last-document" in the second
Send-Document (with no data)."
5. If the client fails to close the job one way or another without the
timeout period, the Printer MUST perform an action to abort, hold, or
process the job, depending on policy. So Jobs aren't always cleanly closed
by the client anyway (using a separate Close-Job operation).
6. The client supplying "last-document" as an Operation attirbute which the
Printer copies to the "last-document" Document Description attribute aligns
better with the PWG Semantic Model where LastDocument is a Document
Description Element, since in the PWG SM the client is able to supply _any_
Document Description attribute which the Printer copies to the Document
object.
7. In summary, the current [RFC2911] "last-document" operation attributes
semantics isn't broken (just unethetic to some), so lets not fix it.
Tom
P.S. I'm only replying to the IPP DL as requested by some members.
-----Original Message-----
From: Dennis Carney [mailto:dcarney@us.ibm.com]
Sent: Monday, April 21, 2003 16:14
To: sm@pwg.org; ps@pwg.org; ipp@pwg.org
Subject: Re: SM> 1 more significant proposed conformance change to the
IPP Documen t object spec
I'm a bit confused: I had the (apparently flawed) impression that the plan
was to deprecate, for a client, using the "last-document" operation
attribute entirely--that is, say the "correct" way to say a job was done
was to do Close-Job. If we do that, we will by definition deprecate the
special case you're discussing below, right? Am I thinking of PSI or maybe
SM?
Since deprecation is only a suggestion, might it make sense to deprecate
"last-document" entirely? (The Printer will still have to support it, but
we're encouraging clients to move to Close-Job.) Do we want to make such a
stand?
Dennis
"Hastings, Tom N"
<hastings@cp10.es To: sm@pwg.org
.xerox.com> cc: ps@pwg.org,
ipp@pwg.org
Sent by: Subject: SM> 1 more
significant proposed conformance change to the IPP Documen t object spec
04/21/03 10:08 AM
In going over my notes I discovered one more significant conformance
changes
proposed change for the IPP Document object from Thursday's April 17,
telecon. This proposal will also go through the two-week comment period.
1. DEPRECATE the way a client can close a Job by supplying an empty
Send-Document operation supplying the "last-document" = 'true' operation
attribute for a Job created with Create-Job and any of (1)
Create-Document/Send-Data, (2) Send-Document, and/or (3) Send-URI. When
the
Printer accepts this no-data Send-Document operation with "last-document"
=
'true' the Printer MUST set the still REQUIRED "last-document" Document
Description attribute. Instead, the client SHOULD use the new Close-Job
operation (which also sets the "last-document" Document Description
attribute).
The Printer MUST continue to support this method of closing a job with an
empty Send-Document request for backward compatibility with existing
clients.
As with the other two mail messages on significant conformance requirements
changes, I will not edit this comment into the spec until we reach
consensus
on Friday, May 1.
Please send comments.
Tom
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 03:05:08 EDT