1) Windows users can only send one document per job.
2) Solaris users can send multiple documents per job, but they
must all have the same format, despite the generality of the LPD
protocol. I think that most if not all other Unix systems have
the same limitation.
So that doesn't leave very many people with the capability that we
are removing from version 1.0.
Bob Herriot
> From rturner@sharplabs.com Mon Sep 22 16:12:02 1997
> From: "Turner, Randy" <rturner@sharplabs.com>
> To: "'ipp@pwg.org'" <ipp@pwg.org>
> Subject: RE: IPP> Document attributes
> Date: Mon, 22 Sep 1997 15:34:30 -0700
> X-Priority: 3
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.0.1458.49)
> Sender: ipp-owner@pwg.org
> X-Lines: 90
>
>
> Does this seem kind of limiting, to restrict all documents in a
> particular job to have the same document format? It doesn't
> seem hard to imagine a 2-document job wherein one file
> is PCL and another Postscript. If the document attribute
> says "application/vnd.pcl" then the printer would probably
> trash the 2nd Postscript job.
>
> Just checking to see if we haven't got a hole in this
> somewhere....
>
> Randy
>
>
> > -----Original Message-----
> > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
> > Sent: Monday, September 22, 1997 3:27 PM
> > To: ipp@pwg.org; rturner@sharplabs.com
> > Subject: Re: IPP> Document attributes
> >
> > I think that we agreed not to decide on the format of attributes that
> > have a separate value for each document by eliminating document-name,
> > and stating that all documents in a job have the same document-format,
> > meaning that document-format is a job-level attribute.
> >
> > Document-URI is still a problem unless either we eliminate Send-URI
> > (my
> > preference) or eliminate document-URI as a job attribute until a later
> > version.
> >
> > Although we previously decided not design a format for per-document
> > attributes until a later version, I pointed out that an attribute
> > 'foo'
> > could take on a "dictionary" value whose values might be "default=XYZ"
> > and "3=ABC" to indicate that the job level 'foo' attribute has a value
> > of "XYZ" and document-3 has a value of "ABC". Such a solution is not
> > precluded by the current design.
> >
> > Bob Herriot
> >
> > > From rturner@sharplabs.com Sun Sep 21 09:49:57 1997
> > >
> > > Ok, so we have these actual document attributes that we could
> > admittedly move
> > > into "job document attributes" just to save us the work this time of
> > actually doing
> > > the work to support document attributes. This might be
> > > problematic for future implementations that actually *DO* the
> > > document attribute model correctly, having to be backward-compatible
> > > with our "hacked" version of document attributes of IPP 1.0.
> > >
> > > I thought maybe we could allow a placeholder in the model/protocol
> > for
> > > V 1.0 for document attributes, so that we could easily integrate
> > this in
> > > the future with very little work.
> > >
> > > Concerning the "job-document-attribute" proposal...
> > > I'm assuming that the send-document operation allows these
> > "job-document"
> > > attributes to be included (I can't remember the send-document
> > specifics from the
> > > model document...).
> > >
> > > Randy
> > >
> > > Ira Mcdonald x10962 wrote:
> > >
> > > > Hi Randy,
> > > >
> > > > I think we agreed that JOBs could have descriptive attributes
> > > > (either single- or multi-valued??) about the associated
> > > > document(s), which apply unless (in a future version of IPP)
> > > > they are overridden at the (future) DOCUMENT object level.
> > > >
> > > > I speculate that the following JOB level attributes are
> > > > necessary or desirable in IPP 1.0:
> > > >
> > > > [job]document-name
> > > > [job]document-URI (to support Send-URI)
> > > > [job]document-format
> > > >
> > > > Cheers,
> > > > - Ira McDonald (outside consultant at Xerox)
> > > > High North In
> > > > 906-494-2434
> > >
> > >
> > >
> > >
>