RKD> Although it may require some duplication of
RKD> attributes, I believe my scheme to be simpler
RKD> for the following reasons:
RKD> Your scheme will require some addditional
RKD> structuring of the data on Create Job to
RKD> be able to define which document a set of
RKD> attributes is associated with. This means extra
RKD> parsing and processing of the input stream.
RKD> My proposal does not require this.
RKD> Your scheme always requires the client build
RKD> this information up in the Create Job, using
RKD> the forward attribute when it does not have
RKD> the information available when Create Job is
RKD> built. My proposal only requires this if the client
RKD> wishes to have up-front validation. A well-
RKD> behaved client should not require validation,
RKD> since it queries the printer before it builds the
RKD> Create Job request.
RKD> Your scheme requires the Printer remember
RKD> the per document attributes, and then be
RKD> able to recall them when actually processing
RKD> the data for that job. My proposal does not
RKD> require this.
I think that this idea started out as a simplification.
We need to keep it that way or abandon it. We need to
be clear about what problem we are solving here.
RKD> I thought that the discussion that triggered this
RKD> idea was to allow the Printer to validate the PDLs
RKD> of all documents in the job, at Create Document
RKD> time. Is it more than this?
Bob Herriot
> From rdebry@us.ibm.com Mon May 12 14:53:59 1997
>
> Bob, here is an alternative that I think my systems
> could easily handle:
>
> If the client wants confirmation that the job will be accepted
> before it sends any document content. then it must include
> all of the attributes it wants validated up front in create job.
> If it doesn't care, then it does not have to.
>
> Document attributes in the create job are not in any specific
> order and are viewed just as a collection of attributes, i.e.
> they are not in document order nor are they to be associated
> with particular documents in some fashion. The request just
> says, here is a bunch of attributes, can the Printer support
> them?
>
> For example, if I had a job with the following documents --
> a Postscript document, a PCL document, a PCL document,
> a text document, a PCL document, and a Postscript
> document, the attributes in create job would be
>
> <postscript><pcl><text>,
>
> not
>
> <postscript><pcl><pcl><text><pcl><postscript>.
>
> Attributes would be repeated in subsequent send document
> operations as part of the document they belong to. This
> allows the server to validate the attributes, but not have to
> save the values and associate them with the
> documents which may come later in the stream. Clients which
> don't care about up front validation don't have to declare
> document attributes in create job, they would be part of each
> document just as in the validation case.
>
> This would make the server side much simpler. It does not
> add any complexity to the client, and only increases the
> over-all size of the data transmitted sightly larger.
>
> Comments??
>
> Roger K deBry
> Senior Techncial Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry@us.ibm.com
> phone: 1-303-924-4080
>
>
> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/12/97
03:06 > PM --------------------------- > > ipp-owner @ pwg.org >
05/12/97 02:22 PM > Please respond to ipp-owner@pwg.org @ internet > > > To:
Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet > cc: > Subject: Re: IPP>MOD
- Multiple documents per job > > I am proposing a mechanism that is similar to
what PDF and PostScript use > when a value cannot be computed until later in a
job. > > If a client does not know the value of some attribute when it is >
performing the CreateJob operation, it includes the attribute, but > sets its
value to "forward". This lets the server know that the client > is specifying
the information and to expect the > information later. Some servers will not be
able to handle certain > attributes later. It may be that "forward" needs to be
more > specific, namely "before document" "after document" or "end of job". > >
For example, the number-of-documents may be "forward, end-of-job" > because the
client doesn't know until the entire job is submitted. > > I don't want to
propose a general mechanism at this time, but I > wonder if you could ask the
people who didn't want to specify everything > up front to be more specific
about what they could specify up front > and what they could not. Also, ask
them when they would be able > to specify the information: before-the-document,
after-the-document, or > end-of-job? I would hope that the list of items > that
have to wait is small. > > Bob Herriot > > > > From rdebry@us.ibm.com Mon May
12 12:55:19 1997 > > > > Can you say more ... I'm not clear on exactly > > what
you are proposing? > > > > > > To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @
internet > > cc: > > Subject: Re: IPP>MOD - Multiple documents per job > > > >
Perhaps the fall back position is that all attributes are up front > > in Create
Jobs, and that an allowed value is "forward". Then > > a server knows that if
the job has no forward values, it knows > > all it needs to know about the job
in advance. > > > > > From rdebry@us.ibm.com Mon May 12 07:23:05 1997 > > > > >
> I polled our operating systems on the proposal to handle > > > multiple
document jobs by carrying all of the document > > > attributes for each document
up front in the Create Jobs. > > > > > > The response was nearly unanimous that
this is too difficult > > > for existing printing systems to comply with. > > >
>
> > Roger K deBry > > > Senior Techncial Staff Member > > > Architecture and
Technology > > > IBM Printing Systems > > > email: rdebry@us.ibm.com > > >
phone: 1-303-924-4080 > > > > > > > > > > > > > > >