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