Subject: IPP> Document attributes

From: "Turner, Randy" <[email-masked]>
Date: Sat, 20 Sep 1997 10:38:56 -0700

I know we agreed not to have any document attributes but isn't
"document-format-attribute" a document attribute?

Randy

---

From: [email-masked] (Robert Herriot)
Date: Mon, 22 Sep 1997 15:27:05 -0700

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: "Turner, Randy" <[email-masked]>
Date: Mon, 22 Sep 1997 15:34:30 -0700

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
>

---

From: Tom Hastings <[email-masked]>
Date: Tue, 23 Sep 1997 11:13:24 PDT

Randy,

What kind of a place holder did you have in mind for document attributes?

Such a place holder might be a way forward, as we have done for the
'dictionary' attribute syntax (by reserving the type code).

Tom

---

From: [email-masked] (Robert Herriot)
Date: Tue, 30 Sep 1997 16:35:25 -0700

If I understand your comments correctly, we are talking about two
different parts of a Unix spooler. 

I am talking about the standard spooler shipped with a System V UNIX
system. It assumes that all document data is of the same format and any
conversion (filtering) it performs on one file it does on all files.

You are talking, I think, about a customized interface script rather
than the standard interface script.  I agree that a customized
interface script could use a different filter for each file.  But that
doesn't change the fact that customers using the standard System V UNIX
spooler and standard interface script cannot do this.

Bob Herriot

> From [email-masked] Mon Sep 29 13:56:59 1997
> 
> Umm...beg your pardon?  I'm not sure exactly what you mean when you
> say "You were just lucky to have a smart printer" below.
> 
> Fact is, the printer is actually pretty dumb, since it is our
> interface/filter software that does all the work.  And the examples
> I cited work for almost any kind of network printer when used with
> our software.
> 
> The point is, I don't think it is at all accurate to say that "no
> Unix system does this and that" within the context of this topic.
> 
> 	...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:
> > 
> > Jay,
> > 
> > You were just lucky to have a smart printer in the examples you cite below.
> > 
> > In both the System V and the BSD Unix examples you cite below, all of the
> > document data passed through the system as plain text data until it reached
> > the printer which auto-sensed its type: PostScript, PCL or text and then
> > printed it correctly.
> > 
> > If your printer didn't accept text, for example, the System V spooler would have
> > run the text-to-PostScript filter on all three files, giving you a print out of
> > the PostScript and PCL files in their raw form.
> > 
> > Bob Herriot
> > 
> > > From [email-masked] Fri Sep 26 19:08:57 1997
> > >
> > > (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
> > >
> > >
> > > Robert Herriot wrote:
> > > >
> > > > > 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
> > > > > > >
> > > > > > >