IPP> REQ - Comments/issues on Feb 17 (01a) Requirements docu

IPP> REQ - Comments/issues on Feb 17 (01a) Requirements docu

IPP> REQ - Comments/issues on Feb 17 (01a) Requirements docu

Randy Turner rturner at sharplabs.com
Mon Mar 10 18:12:00 EST 1997

See my comments <RT> below, thanks


rdebry at us.ibm.com wrote:
> Tom, I've looked at your comments and have responded to several of them.  I am
> assuming that Don, as editor of the requirements document has the final say on
> what changes are made. These are my suggestions:
> ..snip..snip..
> 3. ISSUE 02 - Add requirement that the client can
> specify in each operation whether the responses
> to the IPP operation is to be in HTML or IPP.

<RT> IMHO, for the requirements document, talking about requests and
<RT> at this level is too detailed. I thought the requirements document
<RT> specifies printing problems to be solved from a layman's

> RKD>> Isn't this a protocol/implementation issue
> RKD>> and not a requirement?
> ..snip..snip..
> 5. Page 5, 2.1.1 Finding or locating a printer:
> Problem: Should be able to find from other desktop tools, in addition to
> browsers.
> Suggested fix:  add "or other desktop tool/application" to the end of the
> second sentence.

<RT> Can we just say that finding or locating a printer would primarily
<RT> be accomplished through a directory-service enabled client? I think
<RT> this is the only mechanism we have talked about for dynamically
<RT> discovering the existence of IPP services within a particular
<RT> domain.

> RKD>> Sounds reasonable.
> ..snip..snip..
> 7. Page 7, 2nd to last paragraph, first line: Change "Print jobs will be
> submitted by background" to "Print jobs will also be submitted by background".

<RT> IMHO, this should not be a requirement. Its a possible
implementation, but
<RT> should not be a requirement


> 9. ISSUE 03 - Page 8, 2.1.5 Viewing the status of a submitted print job
> Problem: Without some notification defined, interoperability is a serious
> problem.  Also the model document has some notification methods defined.
> I believe that a program needs to be able to receive notification that it
> can parse, so just e-mail and html append, while necessary, are not
> sufficient notification methods. Last paragraph says that IPP won't define
> notification capability.

<RT> I agree with Roger. For the requirements document, we should
<RT> just say that support for asynchronous notification of job status
<RT> be supported; any details with regards to how its supported would
<RT> in a separate protocol section, chapter, or document.

> RKD>> To my remembrance, we have never discussed this as
> RKD>> a requirement. Why must we define a machine parsable
> RKD>> notification? Cast this in end-user terms.


> 19. Page 16, 4. Objective of the Protocol
> Add as an objective that IPP may be used directly by the operating system.

<RT> Should we really be suggesting how and where IPP is implemented? 

> 21. Pages 26-...
> We've agreed in the Model group to change the response on the Print operation
> from getting Printer status, to getting job status that includes whether the
> Printer is stopped.
> In particular Page 28 should be something like:
>    job-state=pending, job-state-reasons=printer-stopped
> RKD>> Does the requirement have to precisely reflect
> RKD>> the model? I don't believe so. The objective of
> RKD>> the requirement is to describe in (hopefully)
> RKD>> general terms what the end user expects. If we
> RKD>> choose to provide more information or use slightly
> RKD>> different words in the model that should be okay.
> RKD>> Personally, I'd be suspicious of a requirments
> RKD>> statement that precisely reflected the terminology
> RKD>> and implementation of the protocol. Would sound like
> RKD>> we wrote the specifciation first and then justified
> RKD>> it by writing the requirement later.

<RT> I agree with everything Roger said. Ditto.



Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com

More information about the Ipp mailing list