/HOLST
I think we agreed Tuesday night that the UPDF was intended to describe
the printer in a OS and transport independent manner. So it should be
sufficient for the UPDF to say that, in this case, that the printer
suports two sided printing or some other feature. I don't think the
charter of the UPD extends to the binding or suggested binding of
anything described in the UPDF to any transport mechanism. The UPD
can and probably should suggest implementations, but the exact
implementations are up to implemntor, and the implementation will
likely be different for various OS's and transports.
If the transport is IPP, then the features will map into the Job
template, or if the transport is something simple like HPPCL then it
will map into an escape, or perhaps some transports won't support it
all.
Regards,
Ben Brezinski
______________________________ Reply Separator
_________________________________
Subject: RE: UPD> UPD Charter Comment: doesn't mention IPP
Author: Non-HP-hastings (hastings@cp10.es.xerox.com) at
HP-Vancouver,mimegw1
Date: 9/28/98 4:49 PM
I did not intend that UPDF only work with IPP, but I'm still concerned
about
how UPDF will work with IPP. I agree that UPDF should work with any job
submission protocol and be as independent of job submission protocols as
possible. On the other hand, if that means that a job submitted by a print
driver using UPDF will be unable to contain any of the IPP Job Template
attributes in the protocol, then I think we have a problem.
So help me understand the intended architecture of a print driver that is
using a UPDF description and the new print API with an IPP Printer. How do
the capabilities described in the UPDF file about the printer, say, that it
can do two-sided printing or support xxx media, get into the IPP protocol?
Thanks,
Tom
-----Original Message-----
From: Sandra Matts [mailto:sandram@boi.hp.com]
Sent: Wednesday, September 23, 1998 09:20
To: 'upd@pwg.org'
Subject: FW: UPD> UPD Charter Comment: doesn't mention IPP
I agree with Don. It important to keep it as independent as possible from
the
transport mechanism. However I can see it will be very important to have
the implementer's guide which will show how the UPDF can be wrapped
in a protocol.
The req. doc currently only references IPP - it doesn't have it as a
requirement.
I'm trying to allocate some time to updating the req doc. I'll
try to post it tomorrow.
Sandra
-----Original Message-----
From: don@lexmark.com [SMTP:don@lexmark.com]
Sent: Tuesday, September 22, 1998 9:49 PM
To: Hastings, Tom N
Cc: Upd@pwg.org
Subject: Re: UPD> UPD Charter Comment: doesn't mention IPP
Sorry Tom, I don't think the UPD charter _has_ to say anything about IPP.
It
_will_ talk about late binding and print attributes in general but UPD
should
not be limited to an IPP environment. I have no objection to mentioning
IPP
as
a client to printer protocol that might take advantage of late binding but
I
do
not believe we should structure UPD around IPP.
Don
"Hastings, Tom N" <hastings%cp10.es.xerox.com@interlock.lexmark.com> on
09/22/98
07:47:31 PM
To: upd%pwg.org@interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
bcc: Don Wright/Lex/Lexmark
Subject: UPD> UPD Charter Comment: doesn't mention IPP
How does the new UPD project fit with IPP?
The PWG would be making a serious mistake if the new UPD project was only
providing the old style of passing print instructions in the PDL data,
thereby not allowing UPD printer drivers to make use of the IPP method of
putting the print instructions in the protocol as an application/ipp MIME
type in front of (but separated from) the PDL data.
The charter includes an API to a OS independent PDL generator. It would be
nice if an OS that is supporting the IPP protocol could intercept the API
calls and use the semantics being passed in the API calls to wrap the IPP
protocol around the document as an application/ipp MIME type. Therefore,
the UPDF format needs to also include means to specify IPP Job Template
attributes (and maybe operation attributes too?).
So the UPD charter has to say something about IPP. (Presumably also the
UPD
requirements which are still being developed).
Tom Hastings
(310) 333-6413