Subject: MOD - Re: IPP> create job IPP operation

From: Tom Hastings <[email-masked]>
Date: Wed, 18 Jun 1997 13:00:07 PDT

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 <[email-masked]> 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 [email-masked] 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
>> 
>> 
>> 
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                    
>
>