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

BEN_BREZINSKI at HP-Vancouver-om1.om.hp.com BEN_BREZINSKI at HP-Vancouver-om1.om.hp.com
Fri Oct 2 19:43:55 EDT 1998


     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 at 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 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