I agree. We can't make a career of fine tuning the requirements.
We aren't writing military spec requirements here.
> These are my suggestions:
>
>
>1. Mention V1.0 some where and that V1.0 is only end-user.
>RKD>> Sounds reasonable
>
>2. ISSUE 01 - Need to flag which requirements are for V1.0 and which are
>for a later version.
>RKD>> I believe that everything in the current
>RKD>> document is end-user related, so is
>RKD>> therefore a V1.0 REQUIREMENT. We have
>RKD>> discussed some things as being too complex
>RKD>> to implement in V1.0, but does that make make
>RKD>> it not a requirement? Isn't it okay not to meet
>RKD>> all requirements?
Gee! I had thought that requirements were required to be met
in our specification. My suggestion is that anything that we
don't absolutely need in V1.0 should be flagged as being in V2.0
and that we should agree on such immediately.
Also I had thought that we had agreement that anything that we
didn't need for V1.0 we would flag in the requirements documents
as not being in V1.0. So the operator and system administrator
requirements that are in the current document should just be flagged
as not being in V1.0.
>
>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.
>
>RKD>> Isn't this a protocol/implementation issue
>RKD>> and not a requirement?
I talked with Carl-Uno and maybe the Requirements document is
just the requirments that the end-user actually sees. In this
case, my suggested requrement can be moved to the Model document
in the up front section on Architecture Assumptions.
Scott,
How does that sound?
>
>4. Page 5, 2.1 End-User 2nd para:
>Problem: Cancelling a job not mentioned, and modifying a job is not
>currently a V1.0 operation.
>Suggested fix: change "altering the print job" to "cancelling the print job".
>If modifying a job is a requirement for V2.0, also add something like:
>"For Version 2.0, modifying a submitted job."
>
>RKD>> See response to Issue 01.
Gee! I think that the end-user functionality needs to be (and is
already) mentioned in the Requirements document. I was just trying
to clarify the end-user requirements. Since the way that it is currently
written suggests that we need a ModifyJob operation. I agree that we
don't need a ModifyJob operation for IPP V1.0 and I wanted to make sure
that the Requirements couldn't be mis-understood to be saying that we
do need an opeation that modifies (alters) a job.
>
>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.
>
>RKD>> Sounds reasonable.
>
>6. Page 7, what the user typically wants to be able to determine about
>status on jobs queued: add "where is(are) my job(s) in the queue?"
>
>RKD>> Sounds reasonable.
>
>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".
>
>RKD>> Sounds reasonable.
>
>8. Page 8, top, add:
> - stapling
> - one sided vs. two-sided printing
>
>RKD>> We have said that the list is not exhaustive.
>RKD>> Do we really need to add these two? If so,
>RKD>> then what other's have we missed?
I didn't intend to make the list exhaustive, but I did want to add
the most useful late binding type of decisions that many PDLs
and printers support today. These two are the most important to me
(as an end-user).
>
>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.
>
>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.
Ok, then lets move this concept to the Model document Architecture
Concepts section: that IPP is to serve end-users and programs that want
access to the same information that end-users can get. So that anything
that an end-user can view, a program can obtain from the Printer
and parse. The requirement that a program can get IPP information
and parse it so that a program can combine the output from different
vendors into a single co-herent display to an end-user is
the main requirement that says that IPP needs to be more than just HTML
responses.
>
>Suggested fix: IPP will define severval notification methods meeting the
>following requirments:
> 1. A method that is ubitquous and intended for system to human notification
> (e-mail).
> 2. A method that is lightweight and intended for system to human notification
> 3. (new) A method that is lightweight and intended for system to program
> notification.
>
>10. Page 8, section 2.2 Operator and its sub-sections should be labeled
>IPP V2.0.
>
>RKD>> I don't know if we need to label the section as
>RKD>> V2.0, but we clearly need to say that these are
>RKD>> V2.0 operatiions. Same goes for 2.3.
Agreed that we need to indicate that these sections are V2.0.
>
>11. Page 9, section 2.3 Administrator - same
>
>12. ISSUE 04 - Page 11, 3. IPP Scenarios, three physical configurations:
>Problem: Has fan-out, but needs to add fan-in without adding any additional
>complexity to V1.0. Fan-in is useful for giving different personalities
>(i.e., different defaults and different capabilites to the same output
>device, especially now that many Printer have multiple interpreters in them).
>Also fan-in allows the Administrator to specify different access control to
>different capabilities of a single output device. To the end-user
>and to the IPP V1.0 protocol, such fan-in will be transparent and behave
>just as if each accessible Printer controlled a separate output device.
>The user might happen to notice that quering jobs on several fan-in Printers
>may show the same jobs and that the state of the fan-in Printers seems
>to change in lock-step, but that is the only end-user observable consequence
>of supporting fan-in of Printer objects to a single output device
>(or a set of fan-out output devices).
>
>Suggested fix: Add the following sentence to the third bullet:
>"Each IPP Printer object may be associated one-to-one with a disjoint set
>of output devices (fan-out) or multiple IPP Printer objects may be associated
>with a disjoint set of output devices (fan-in)."
>
>RKD>> I think fan in could be added, but I don't care for your
>RKD>> words. Does veryone else agree that we should add fan-in?
>RKD>> Tom seems to be the only one I've heard from?
No, Keith has suggested that fan-in is a way to solve the problem of
output devices with multiple personalities, e.g., that support multiple
PDLs. See the issue on page 19 under file-type adornment.
If we don't want to add fan-in in the User Requirements document, since
by definition, the end-user cannot tell about fan-in (on purpose),
we can just move the concept of fan-in in the beginning of the Model
document in Section 3.1 where we discuss configurations supported
where the Architecture Assumptions section will be.
>
>13. Page 12, section 3.1, Printer Discovery
>Change "Printer" to "Directory" in:
>"The actual protocol used between the client and the Printer is
>considered outside the scope of IPP."
>
>RKD>> Agreed.
>
>14. Page 12, some of the bulleted items are results, not inputs to a
>directory query filter, such as "how to get more information".
>Suggested fix: Separate what can be filtered on input from what can
>come back from a Directory entry.
>
>RKD>> I think the section is correct as it stands, all
>RKD>> are things to be considered when locating a printer.
>RKD>> I don't think we need to break the bulleted list into
>RKD>> inputs and outputs.
I think that it is clearer to the rest of us working on the Directory,
Model and Protocol which items are filterable and which are purely
outputs that the end-user cannot specify a filter on a query.
>
>15. Page 13, add help desk as something that can come back, but can't
>be filterred upon in the query.
>
>RKD>> See previous.
>
>16. Page 13, 3.2 Driver Installation
>Add "provide instructions to the end-user for installing the driver".
>Currently you get get drivers, but you need to know some magic, such as
>looking in some magic directory for an .EXE file and double clicking on that.
>Phew!!!
>
>RKD>> I guess this could be optionally provided.
>RKD>> I don't see the content of a response as being
>RKD>> architected as part of IPP anyway.
I just wanted to get another URL added to the Printer object that would
contain help, like instructions about what to do to actually do the
installation about installing the driver. The situation today is not
user-friendly and I just wanted to solve a real end-user usaability problem
that we Printer vendors have today.
>
>
>17. Page 14, last line, add "ready and defaulted" to: "Job submission
>attributes supported/required".
>
>RKD>> I'd need to read the model document again to see
>RKD>> if this belongs here as a requirement.
>
>18. Page 15, 3.5 Asynchronous Nofication
>Clarify whether this is notification to an end-user (V1.0) of printer problems
>with his/her job and problems with the Printer for which his/her job is
>pending versus (V2.0) and operator that wants notification independent of
>whether he/she has a job submitted or not.
>
>RKD>> Does it matter? We will say that operator things are V2.0.
I wanted to clarify that an end-user cannot get notifications from a
Printer, unless he/she has submitted a job to that Printer.
In other words, the Printer is not going to have to be a notification
service in order to meet the Requirements document.
>
>19. Page 16, 4. Objective of the Protocol
>Add as an objective that IPP may be used directly by the operating system.
>
>RKD>> I agree.
>
>20. ISSUE 05 - Page 16, after 4.2 add requirements for Extensibility
>(that BSD didn't have). I suggest something like:
>
>4.3 Extensibility
>The IPP protocol is intended to be extensible by several different means
>that facilites interworking and prevents implementation collisions:
>
>- Provide a process whereby implementors can submit proposals for registration
>of new attributes, new enumerated values to existing attributes, and new tags
>for attributes or attribute values for review and approval. IANA will be the
>repository for such accepted registration proposals after review.
>Such a process has been used for the Printer MIB (RFC 1759). See type2enum.
>
>- Provide a process whereby implementors can submit proposals for registration
>of new attributes, new enumerated values to existing attributes, and new tags
>for attributes or attribute values that do not require review and approvel.
>IANA will be the repository for such registrations.
>Such a process has been used for the Printer MIB (RFC 1759). See type3enum.
>
>- Provide syntax in the protocol so that implementor may add private
>(unregistered) attributes, enumerated attribute values, and tags.
>
>RKD>> You have focused on attributes ... don't we need to be
>RKD>> even more general? What about adding new operations, etc?
Adding new operations is very much harder to do than adding attributes
as implementor extensions without upsetting interworking.
I was trying to be simple for IPP V1.0.
>
>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.
Well, no need to change the Requirments document if we all agree that
we don't need to pay too close attention to the words in the
Requirements document in doing the Model.
My actual view is that the Model work feeds back on the requirements
and the updating the Requirements as the Model develops helps improve
the requirments. In other words, the Model work gives us greater clarity
on what can be done and that reflecting that in the requirements document
helps prevent the model from being tied down to first ideas.
>
>22. Pages 26-...
>In the model group we've changed the name of the printer state from
>"printing" to "processing" to be more general, and less restrictive.
>
>RKD>> See previous response.
>
>23. Pages 26-...
>The state of the job should be renamed from "spooled" to "pending", since
>the job may or may not be spooled.
>
>RKD>> See previous response.
So perhaps we need to add a statement in the Requirements document
to cover the above that the actual terminology used in the Requirements
document need not be reflected in the standard. The purpose of the
Requirements document is to give a description of the "kind" of responses
that the end-user might see.
>
>24. ISSUE 06 - Page 35, submitting a job to a non-spooling Printer and
>printer jams and the end-user chooses to disconnect.
>Is this a requirement for the IPP protocol or not?
>
>RKD>> I think it is!
I know that this is a hot topic.
>
>25. Page 52, 8.26 Asynch notification
>Separate the cases of any job fails for which I've submitted a job, from
>my job failed. Two separate cases.
>
>RKD>> Isn't the second just a special case of the first?
Yes, but some users want to know when any job has a problem that might
affect their job and other users only want to know about problems
about their own jobs, because they have faith that others will fix their
own problems (or the operator is attentive).