Subject: Re: IPP> Document attributes

From: [email-masked] (Robert Herriot)
Date: Tue, 23 Sep 1997 16:44:53 -0700

> From [email-masked] 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:   [email-masked]          --
> --  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 [email-masked] Mon Sep 22 16:12:02 1997
> > > From: "Turner, Randy" <[email-masked]>
> > > To: "[email-masked]'" <[email-masked]>
> > > 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: [email-masked]
> > > 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:       [email-masked] [SMTP:[email-masked]]
> > > > Sent:       Monday, September 22, 1997 3:27 PM
> > > > To: [email-masked]; [email-masked]
> > > > 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 [email-masked] 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
> > > > >
> > > > >
> > > > >
> > > > >
> > >
>

---

From: Jay Martin <[email-masked]>
Date: Fri, 26 Sep 1997 21:17:20 -0400

(Sorry for not responding sooner, as I have been out of the office.)

Unix System V spoolers allow you to configure a queue with a
specified set of "content types"...where the list can be more
than one type.

On Solaris 2.5.1 I just printed a set of documents to a single
"printer" in which each document had a different data format
(text, postscript, pcl).

On BSD Unix, there is no concept of "content type", so the LPD
agent (ie, lpr) constructs the "cf" (control file) such that
the documents are specified as having a "normal" (my term) data
type.

Why would someone want to do this?  For *exactly* the same reasons
as we wanted multiple documents for IPP: printing a number of
documents from a document repository, where each document may be
of a different type (postscript, pdf, text, etc).

	...jay