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.
Bob Herriot
Tom's proposal of adding
> From hastings@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@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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>