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
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
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.
Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/12/97 03:06
ipp-owner @ pwg.org
05/12/97 02:22 PM
Please respond to ipp-owner at pwg.org @ internet
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet
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.
> From rdebry at 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
> 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 at 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 at us.ibm.com> > phone: 1-303-924-4080