Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
My responses follow:
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/28/97 04:07
PM ---------------------------
ipp-owner @ pwg.org
02/28/97 02:06 PM
To: rdebry @ vnet.ibm.com at internet
cc: ipp @ pwg.org at internet
Subject: Re: IPP>MOD - Suggestions for new introduction
At 11:33 AM 2/28/97 PST, you wrote:
>Classification:
>Prologue:
>Epilogue: Roger K deBry
>Senior Techncial Staff Member
>Architecture and Technology
>IBM Printing Systems
>email: rdebry at us.ibm.com>phone: 1-303-924-4080
>>I've posted a suggested new introduction to the Model Document in
>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/newintro.txt>
Roger,
thanks for doing this. It certainly helps us quite a bit further.
I have a few comments:
1) When you talk about users, you limit it to human users and assume human
interfaces. Obviously an application could use IPP directly without human
intervention. I think this should be called out somewhere.
RKD> Applications are shown using IPP directly, however perhaps the optional
RKD> printer driver and spooler confuses this. The text also suggests that
RKD> applications can use IPP directly.
2) In the picture, you have the Brower connected directly to Transport.
My suggestion is that it is connected to the IPP Client (I suppose this is
one of the points on which we not yet have agreement).
RKD> No, I don't think that the browser is ever connected to an IPP
RKD> client. It may access the server, however.
3) On Notification Service you state that we assume that this exists. My
assumption is that you could have an implementation that does not support
this. You could have an IPP Client regularly pull the IPP Server for status
information instead (not so elegant, but possible - many implementations
use this now).
RKD> I'd certainly be willing to make it an optional component if
RKD> everyone else agrees.
4) You also claim that a Directory Service is assumed. You could advertise
your Printers on Web pages as an alternative to listing them in a
directory, hence this is also not a service that has to be present.
RKD> I intended that this be an optional component. I'll reword if this
RKD> is not clear.
5) The relationship between an IPP Server and a Printing Service is not
very clear in the text. I assume that the IPP Server is a component of the
Printing Service. We need to say that.
RKD> I tried to suggest that the IPP server and the Printing Service were
RKD> both components of an IPP Printer, where printing service referes to
RKD> spooling, scheduling, kinds of function.
Again thanks,
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com