IPP> RE: UPD> UPD Charter Comment: doesn't mention IPP

IPP> RE: UPD> UPD Charter Comment: doesn't mention IPP

IPP> RE: UPD> UPD Charter Comment: doesn't mention IPP

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Sep 28 19:49:32 EDT 1998


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 at boi.hp.com]
Sent: Wednesday, September 23, 1998 09:20
To: 'upd at 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 at lexmark.com [SMTP:don at lexmark.com]
Sent:	Tuesday, September 22, 1998 9:49 PM
To:	Hastings, Tom N
Cc:	Upd at 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 at interlock.lexmark.com> on
09/22/98
07:47:31 PM

To:   upd%pwg.org at 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







More information about the Ipp mailing list