Subject: IPP>MOD - Multiple documents per job

From: Roger K Debry <[email-masked]>
Date: Mon, 12 May 1997 10:18:18 -0400

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: [email-masked]
phone: 1-303-924-4080

---

From: [email-masked] (Robert Herriot)
Date: Mon, 12 May 1997 12:32:42 -0700

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 [email-masked] Mon May 12 07:23:05 1997
>

---

From: Roger K Debry <[email-masked]>
Date: Mon, 12 May 1997 15:50:25 -0400

Can you say more ... I'm not clear on exactly
what you are proposing?

Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/12/97 01:44
PM ---------------------------

        ipp-owner @ pwg.org
        05/12/97 01:38 PM
Please respond to [email-masked] @ internet

To: Roger K Debry/Boulder/IBM, ipp @ pwg.org @ internet
cc:
Subject: Re: IPP>MOD - Multiple documents per job

---

From: [email-masked] (Robert Herriot)
Date: Mon, 12 May 1997 13:12:39 -0700

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 [email-masked] Mon May 12 12:55:19 1997
>

---

From: Roger K Debry <[email-masked]>
Date: Mon, 12 May 1997 17:49:04 -0400

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

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/12/97 03:06
PM ---------------------------

        ipp-owner @ pwg.org
        05/12/97 02:22 PM

Bob Herriot

---

From: [email-masked] (Robert Herriot)
Date: Mon, 12 May 1997 18:37:29 -0700

Your suggestion seems to add some additional information that
a client must supply about needed resources. Then the client
supplies the information twice, in a summary at the beginning
of the job and detailed information with each job.  If the
client has such information at the beginning, I would expect
it could fully specify all attributes.

If we are going to have all job attributes at the beginning
of the job (and we may abandon the idea), then I believe 
that any attribute that pertains to a particular document
is identified so that no additional information needs to
be supplied with the document itself, unless a value is
marked as "forward".

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.

Bob Herriot

> From [email-masked] Mon May 12 14:53:59 1997
>

---

From: Roger K Debry <[email-masked]>
Date: Tue, 13 May 1997 09:33:18 -0400

... snip ...

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.

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

> ---------------------- 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 [email-masked] @ 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 [email-masked] 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 [email-masked] 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: [email-masked] > > >
phone: 1-303-924-4080 > > > > > > > > > > > > > > >