IPP> create job IPP operation

IPP> create job IPP operation

IPP> create job IPP operation

Robert Herriot Robert.Herriot at Eng.Sun.COM
Thu Jun 19 15:41:58 EDT 1997


I was proposing that "last-document" be an operation parameter with
no corresponding concept in the job object.  Therefore, I infer that
you agree with the name of "last-document".


For Get-Attributes and GetJobs of document attributes, such as document-name,
I was trying to keep things simple by saying that in a job with 2 or more
documents, the value of each such attribute is a set of the document values.
For example, if I submit a job with two documents whose document-name
attributes are "foo" and "bar", then Get-Attributes with document-name
requested shall return in protocol syntax


   "document-name 3 foo 3 bar" 


This is the syntax for a set of values for document-name.


This solution does not solve the problem of document-attributes that
are multi-valued, but we don't have any yet. So we can defer the solution.


Bob Herriot


> From hastings at cp10.es.xerox.com Thu Jun 19 11:31:30 1997
> 
> 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
> >> >
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >                                                                            
> >> >            
> >> >
> >> >
> >> 
> >> 
> >
> >
> 
> 



More information about the Ipp mailing list