This is a multi-part message in MIME format.
--------------B4F6B6D5C03139084775F05F
Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
--------------B4F6B6D5C03139084775F05F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <33A179B0.1907D7FA at sharplabs.com>
Date: Fri, 13 Jun 1997 09:47:44 -0700
From: Randy Turner <rturner at sharplabs.com>
Reply-To: rturner at sharplabs.com
Organization: Sharp Labs of America
X-Mailer: Mozilla 4.0 [en] (WinNT; I)
MIME-Version: 1.0
To: Robert Herriot <Robert.Herriot at Eng.Sun.COM>
Subject: Re: IPP> create job IPP operation
X-Priority: 3 (Normal)
References: <199706130154.SAA05460 at woden.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I liked option #1 myself but then I started wondering if the IPP client
would know if the document
it has is the last document there will be. If it is continually
receiving documents to send from some
other source (like a windows print driver), then whatever protocol or
API is being used to deliver
the documents to the IPP client for delivery would also have to have a
LAST-DOCUMENT flag
built into the protocol or API. If not, then the IPP client (port
driver, redirector, or whatever) would
not know to set the LAST-DOCUMENT attribute in the SEND-DOCUMENT
request. Rather,
some time later it would be notified that the job stream is closed and
then it would either have to
send something like a CLOSE-JOB or a SEND-DOCUMENT with a zero length
data field, or
something other extra message.
Or, it could just use option #2 and close the connection.
Randy
Robert Herriot wrote:
> 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
> >
> >
> >
--------------B4F6B6D5C03139084775F05F--