Subject: IPP> Re: REQ - ISSUE - Dependencies on browsers

From: [email-masked]
Date: Mon, 3 Mar 1997 18:54:08 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

I don't think that IPP should be dependent on Browsers - current or future.

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/03/97 04:17
PM ---------------------------

        ipp-owner @ pwg.org
        03/03/97 10:24 AM

To: Roger K Debry/Boulder/IBM
cc: don @ lexmark.com@internet, ipp @ pwg.org@internet
Subject: IPP> Re: REQ - ISSUE - Dependencies on browsers

I think we all agree that the requirements document should be
changed to not be called "Requirements for WEB-based broswer
Internet Printing".  We certainly want IPP to be used from any
application on the desktop (transparently to the application and
to the desktop printer driver).

However, browsers are updated on a frequent basis and made available
either free or for a low price, so that one way to deploy a new protocol
is for the browsers to pick up the new protocol.  That may be why
some in the IPP have been advocating a protocol similar to HTTP, but
not actually the same.  Because if IPP is similar, then it will be easier
for the browsers to be updated.  If IPP is not the same as HTTP, then
some of the baggage that will go along with HTTP as it evolves will not
need to be dragged along into IPP.  Those of us who have been advocating
to use HTTP directly have been trying to solve the deployment problem
by being able to use existing browsers.

So we need some kind of requirement that says whether IPP is depending
on using existing browsers, or can wait for the next round of browser
deployments.

The other way that IPP will be deployed is for the "port drivers", also
called re-directors, that sit under the desktop printer driver and relays
to the remote printer what the desktop printer driver thinks is control
and data that the desktop printer is sending to the local printer.

Is there some kind of requirement or assumption that we can agree upon
and add to the requirements that would be something like "Assumed
Deployment Strategy and Timing"?

Tom

At 10:43 02/27/97 PST, [email-masked] wrote:
>Classification:
>Prologue:
>Epilogue: Roger K deBry
>Senior Techncial Staff Member
>Architecture and Technology
>IBM Printing Systems
>email: [email-masked]
>phone: 1-303-924-4080
>
>Don, I gave the requirements document a quick read. The major
>comment I have is that the way the document is currently written,
>it would appear that the only required client interface is a Web
>Browser. While I would agree that using a Web Browser is an
>important requirement, the document should not lead one to
>believe that it is the only requirement!  Since the first paragraph
>in the Terminology section discusses the use of Worl Wide Web
>tools, and Browsers are explicitly dicsussed in the second paragraph,
>there is no need to explicitly call out Browsers (and not mention other
>kinds of clients) in each of the remaining sections.
>
>For example:
>
>Change the title to "Requirements for An Internet Printing Protocol"
>
>In the abstract chnage the first sentence to read "This document
>describes the requirement for An Intrenet printing protocol."
>
>In section 2, REQUIREMENTS, change the first sentence to read
>"The next three scetions identify the requirements of an Internet
>printing protocol ..."
>
>In section 2.1.3, Viewing the status of a printer, chnage the first
>sentence to read "Before using a selected printer or, in fact at
>any time, the end user needs the ability to verify the characteristics
>and status of both printers and jobs queued for the printer."
>
>In section 2.1.4, Submitting a print job, change the 4th sentence
>to read "Printing by reference is defined as submitting a job
>and providing a reference to an existing document."
>
>In section 2.1.5, Viewing the status of a submitted print job, change
>the first sentence to read "After a job has been submitted to a
>printer, the end -user needs a way to view the status of that job
>(i.e. job waiting, job printing, job done)."
>
>

---

From: Patrick Powell <[email-masked]>
Date: Mon, 3 Mar 1997 18:56:42 -0800 (PST)

The problem with assuming that you will sent HTML as printer status
is that it is highly unstructured.  If all you want to do is have
ummm... wetware... read and process the status then you don't need
to worry.   People are very adaptible.  However, if you want to use
the status information for managment tools then you will need something
better.

And before you talk about SNMP as the answer,  note that SNMP has a HORRIBLE
overhead in terms of development, bulk, etc., that simple text based systems
appear not to have.

I like text, simple formats, and the ability to parse it with a minimum
of effort.  I would even reject LALR grammars - simple keyword based
tag/formats would be nice.

Patrick ("Browser De Jour Syndrome") Powell