At 16:53 06/18/97 PDT, Robert Herriot wrote:
>I agree with Tom that we should delete "number-of-documents" because
>we have added a new parameter to Send-Document called (I propose)
>"last-document" which is Boolean.
The problem with "last-document" as a name for the input-parameter,
is that the corresponding job attribute would have to be different,
say, "job-submission-complete". I think that as a principle, the
names of the input parameters and the names of the job attributes
that the input parameters set should be the same.
Using the same names for input parameters as the corresponding job
attributes (when there are both) will also make the encoding more
understandable, since we don't have any separate buckets for input
parameters in the encoding, but have just a single set of attribute
representations as input parameters.
Or were you prosing that we don't need a Boolean job attribute
that indicates whether the job is complete or not? Since we have
the "job-state-reasons" 'job-incoming' value, perhaps that is enough to indicate
to a requester in a Get-Attrbutes request that the job is not yet
complete? If we don't also need a "job-submission-complete" job attribute,
then the input-parameter name "last-document" Boolean is fine.
Not having the "job-submission-complete" job attribute makes it more
mandatory that an implementation that supports Create-Job and Send-Document
also support the 'job-incoming' reason in the "job-state-reasons" attribute.
>>I don't agree with Tom's suggestion of to have a number-of-documents
>that the Printer increments. I would rather allow the user to query
>document-name and get back a set of n document names.
I can agree that we don't really need a "number-of-documents" job
attribute, since the requester can find the number of documents by
requesting a document attribute, such as "document-name"
But that brings up the need for a clarification of how the Get-Attributes
operation returns document attributes.
The Get-Attributes operation for document attributes needs a lot of
clarification. Currently the model document has only 3 document attribtes:
"document-name", "document-format", and "document-uri".
I had thought that the document attributes would come back in groups,
one group for each document if and only if the requester requests a
document attribute, such as "document-name". I thought this, because the
document has been made an object (but with no operations on it).
Bob might be suggesting that the Printer returns a single multi-valued
attribute "document-format", with a separate value for each document.
If a requester supplies:
Create-Job(...)
Send-Document(
"document-format" = 'application/postscript'
"document-name" = 'Monthly Slides' )
Send-Document(
"document-format" = 'application/vnd.hp-PCL'
"document-name" = 'Monthly Report'
Get-Attributes with "requested-attributes" = 'document-format', 'document-name';
input parameter would return:
Result Attributes:
"document-format" = 'application/postscript', 'application/vnd.hp-PCL'
"document-name" = 'Monthly Slides', 'Monthly Report'
I had assumed that the result would group document attributes with some
specified document attribute as the indicator that the next set of
document attributes were following. Either we pick "document-name"
or make up a new read-only status attribute, say, "document-sequence-number"
(as in DPA) that is set by the Printer. I prefer the latter:
Result Attributes:
"document-sequence-number" = '1'
"document-format" = 'application/postscript'
"document-name" = 'Monthly Slides'
"document-sequence-number" = '2'
"document-format" = 'application/vnd.hp-PCL'
"document-name" = 'Monthly Report'
Comments?
Tom
>>Bob Herriot
>>Tom's proposal of adding
>> From hastings at cp10.es.xerox.com Wed Jun 18 15:14:53 1997
>>>>> At 01:04 06/18/97 PDT, Scott Isaacson wrote:
>> >Randy,
>> >
>> >>>> Randy Turner <rturner at sharplabs.com> 06/12/97 06:10PM >>>
>> >> In our current document we have a CREATE-JOB operation that specifies up
>> >> front
>> >> how many documents we have. Is this an unrealistic requirement for
>> >> future IPP
>> >> clients (or drivers) ? Will they always know how many documents are
>> >>coming when
>> >>they first do the CREATE-JOB?
>> >
>> >The model document shows this (number-of-documents) as an optional attribute
>> >in
>> >the Create. If it is there, it better be correct. If not, it is up to the
>> >implementation
>> >to handle as many Documents as might be thrown its way (I claim that it
>> >might fail
>> >after some N+1 documents). Why include it at all if it is optional? It
>> >might help some
>> >implementations with resource management.
>>>> In order to avoid another error condition and a requirement for the
>> server to check for the proper number of documents, lets delete the
>> "number-of-documents" input parameter.
>>>> However, we still need a read-only job attribute that the IPP server
>> SHALL increment by 1 with each Send-Document operation.
>>>> If we can't agree to delete the "number-of-documents" input parameter
>> from Create-Job, then lets at least change the name to something like:
>> "expected-number-of-documents", so that it is not confused with the
>> read-only "number-of-documents" job status attribute which the IPP printer
>> increments as each Send-Document is received. But I don't see the
>> need for such an input-parameter. Lets wait to see if implementations
>> find a need for such an input-parameter and it can be registered later.
>>>> Ok?
>>>> >
>> >As other mail has indicated, we need a flag in the Send-Document
>> >that says this is the last document.
>>>> Also from the PRO disussion yesterday, a requester must be able to
>> issue a Send-Document with no document data and just the flag set
>> to TRUE, since the requester might not have know that it was the
>> last document when the requester did the Send-Document with the data.
>>>> This flag is both an input-parameter of the Send-Document operation
>> that also sets the corresponding job attribute of the same name.
>>>> Randy's protocol document had the input parameter named as an imperitive
verb:
>> "end-document-stream", but that isn't such a good name for the
>> corresonding job attribute. How about the ISO DPA name:
>> "job-submission-complete" for both the input parameter and the read-only
>> job status attribute.
>>>> Tom
>>>> >
>> >Scott
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>>>>>