See my comments <RT> below, thanks
Randy
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
responses
<RT> at this level is too detailed. I thought the requirements document
just
<RT> specifies printing problems to be solved from a layman's
perspective?
>> 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
..snip..snip
> 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
probably
<RT> just say that support for asynchronous notification of job status
will
<RT> be supported; any details with regards to how its supported would
be
<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.
>
..snip..snip..
>> 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.
..snip..snip..
Randy
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com