MOD - Re: IPP> create job IPP operation

MOD - Re: IPP> create job IPP operation

Tom Hastings hastings at cp10.es.xerox.com
Wed Jun 18 16:00:07 EDT 1997


At the PRO meeting yesterday, we review Randy's protocol document
which has lots of operation semantics, which we agreed should be moved
to the Model document.  Amongst these was a Boolean "end-document-stream"
input parameter which we also agreed would become a job attribute,
so that you could do a GetAttributes and see if the job stream was
still open or not.


BTW, we also agreed to call things in the request, 'parameters', not
'attributes'.  Most input parameters of Create-Job and Print-Job wind
up as attributes on the job object.  Parameters are passes in a request
or a response, and attributes exist on an object.


Tom


At 00:43 06/18/97 PDT, Scott Isaacson wrote:
>In the Model document, there is language about a "zero length document" in a
>
>Send-Document operation that is the "flag".  I suppose we do need a flag
>since you might know the document you are sending is the last document and
>it would not be efficient to require another empty Send-Document.  But we
>must
>allow for an empty Send-Document for the case that Bob points out where
>the client does not know it is the end until there are no more documents.
>
>Scott
>
>
>>>> Robert Herriot <Robert.Herriot at Eng.Sun.COM> 06/12/97 07:54PM >>>
>Option 1 (flag for last document) is the best and only reasonable solution.
>
>Option 3 (end job operation) can be accomplished with Option 1 by
>allowing a document of length zero and the last flag on for clients
>that cannot figure out they are done when they send the last document.
>
>Bob Herriot
>
>> From rturner at sharplabs.com Thu Jun 12 17:13:25 1997. 
>
>> 
>> 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?
>> 
>> My feeling is that the clients might not know how many documents will be
>> sent, and
>> if that is the case, we need a mechanism for SEND-DOCUMENT to indicate
>> to
>> the server that this is the last document for the job. There are at
>> least 3 ways to do
>> this off the top of my head:
>> 
>> 1. Have a specific SEND-DOCUMENT attribute or parameter that flags a
>> particular
>>     request as the last document for the job.
>> 
>> 2. Since we are using HTTP 1.1 with persistent connections, just close
>> the TCP
>>     connection from client to host indicating the end of the job stream
>> (or last document).
>> 
>> 3. Have another IPP operation called END-JOB or CLOSE-JOB that
>> unambiguously
>>     encapsulates the job stream within a CREATE-JOB/END-JOB pair.
>> 
>> Comments?
>> 
>> Randy
>> 
>> 
>> 
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                    
>
>



More information about the Ipp mailing list