> From jkm at underscore.com Mon Sep 22 17:03:31 1997
>> Bob,
>> Sorry, but there are *lots* of Unix systems that can accept jobs
> having documents with multiple data formats.
What Unix systems offer this feature?
In my previous email, I stated that the Solaris spooler does not. It
is based on AT&T System V and many other Unix spoolers are based on the
same code. It is possible that other vendors have removed the single
document-format restriction, though considering the required changes,
I doubt it.
The BSD LPD spooler and LPD protocols support multiple formats per job,
so these systems accept jobs with multiple data formats. But the BSD lpr
command does not give access to this feature. It is possible that some
vendors have enhanced the lpr command, but I am not aware of such
changes.
Bob Herriot
>>> ...jay
>> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm at underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>>> Robert Herriot wrote:
> >
> > This is a version 1.0 limitation. But I doubt it will cause much
> > hardship because currently:
> >
> > 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 at sharplabs.com Mon Sep 22 16:12:02 1997
> > > From: "Turner, Randy" <rturner at sharplabs.com>
> > > To: "'ipp at pwg.org'" <ipp at 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 at 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 at Eng.Sun.COM [SMTP:Robert.Herriot at Eng.Sun.COM]
> > > > Sent: Monday, September 22, 1997 3:27 PM
> > > > To: ipp at pwg.org; rturner at 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 at 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
> > > > >
> > > > >
> > > > >
> > > > >
> > >
>