I'm trying to allocate some time to updating the req doc. I'll
try to post it tomorrow.
From: firstname.lastname@example.org [SMTP:email@example.com]
Sent: Tuesday, September 22, 1998 9:49 PM
To: Hastings, Tom N
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.
"Hastings, Tom N" <firstname.lastname@example.org> on 09/22/98
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).