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
>>>