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

From: Tom Hastings <[email-masked]>
Date: Mon, 10 Mar 1997 18:34:20 PST

At 14:51 03/10/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
>
>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. 

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).

---

From: [email-masked] (Robert Herriot)
Date: Tue, 11 Mar 1997 18:05:00 -0800

> Is this a requirement for the IPP protocol or not?

I agree with Roger that a user should be able to stop the operation,
but I don't believe the scenario is correct in the way it is stated.

See my next email for discussion of this issue and many more.

---

From: [email-masked] (Robert Herriot)
Date: Tue, 11 Mar 1997 18:06:20 -0800

Most of this document is fine, but I have identified a number of problems with
scenarios, plus a few nits in the front of the document.

-------------------------
Scenarios which are missing (other than ones mentioned in my discussion of a section):

   print request from windows with no attributes, the Printer may default attributes
     except for production attributes which are embedded in the document data.

   print request from Unix with no attributes, the Printer may default all attributes
     including production attributes.

   print request from some future system with attributes. This scenario seems to
     be covered but doesn't deal with Printers which may not be able to 
     handle explicit production attributes.

   The first two cases should at least be covered in the context where a Printer
     sets defaults for unspecified attributes.

   There are also issue with regard to whether an attribute expresses a requirement
     or "best-effort".  Perhaps there should be a scenario discussing this.

---------------------------

Section 2.1.1  Is "inside the firewall" an appropriate search criteria?  

Section 2.1.1.1. The discussion about creating a queue on UNIX hosts is not right.
   Several sentences in this area should be deleted.

Section 2.1.4, Paragraph 2.  I would expect that a printer would always be 
   able to determine the format. Thus, that requirement should not be in a
   sentence with an 'or'.

Section 2.1.4, Paragraph 3.  The model document on line 335 of V1.5 specifies 
   what happens when a job requests and attribute or attribute value that a 
   printer does not support. Perhaps those details should be in the requirements
   document.

Section 2.1.4, last line.  What is meant by "job default" as an example of 
   parameters to job print request.

Section 2.1.6.  I believe that it is misleading to use the phrase "altering
   the status of a submitted print job" to mean "cancelling a job", especially because
   there will eventually be an operation to alter some attributes of a submitted
   job. Another problem I see with this terminology is that the jobStatus and
   printerStatus groups of attributes cannot be directly changed by any human.

Section 2.2.2. Same comment as for 2.1.6. Also, the "reprioritize either assumes
   that the operator can modify the job-priority attribute via some "set" operaion or 
   that there is some "promote-job" operation. Neither operation has been defined.

Section 2.3.  The bullets which mention pre-print and post-print introduce concepts
   that are too vague. I would replace both by something such as and put it at the
   end of the bulleted list:

   o create, change or customize other printer features.

Section 3, bottom of page 11: Is this list of combinations of case with firewalls
   useful?  I don't think it is.

Section 3, top of page 14: I do not agree with most of the bulleted responses, such as
   got print job, started to print but failed.  The print operation should
   be viewed as an operation to transmit attributes and document data.  The
   operation should primarily report back that the job was sucessfully transmitted
   or it wasn't.  Any job/printer status reported is merely a helpful snapshot that may
   be inaccurate a moment later. Thus, while a Print operation is in progress, however
   long that might be. When the print operation completes, its response indicates
   whether the job was completely received or failed to be received. In the latter
   case, the job does not complete printing, though some may have printed, and it
   would be good for the printer to indicate how much has printed. This operation
   should not be terminated because of a printer jam.

Section 3.6: As stated before, I don't believe the Job Modification should include
   cancelling. Even the mentioned hold and release operations, need not actually
   modify a job. From the stand point of a user model, the hold operation may
   just put the job in a holding tank until it is released.

Section 4.2: Perhaps this is where the mapping between ipp and lpd should exists 
   in order to make the IESG happy.

Section 4.3: I wonder if we will need proxy printers to make the protocol pass
   through firewalls.

Section 8.6, page 26: The model currently does not return the printer state, 
   but it does return the job-state-reasons which will contain the value 
   "printer-stopped" if the printer's state it stopped.

Section 8.8, page 28: There are two cases here.  One is that print operation
   in the client gets notice that its connection to the printer has been dropped
   and the other is that it times out. Note also, that a variant of this scenario
   is that the printer is powered off before the Print starts. This case raises
   lots of potentially bad and unsolvable problems.
   
   In the "get notice" case, the Printer is sufficiently alive that can get 
   information about the problem to the client before it closes the connection,
   and the client can use this information return a reasonable status to the
   caller of the print operation. This status would likely be that the job 
   was aborted.

   In the "time out" case, the client cannot know why the time-out occurred,
   e.g. network down, printer down, or printer too busy to respond. This case
   is probably best handled by assuming that the client will continue transmitting
   when the printer resumes responding.

   The summary of my comments, is that the scenario is incomplete and represents
   several scenarios.

Section 8.9: There are certain assumption about security here that should not
   be a requirement document with regard to the exchanges that take place.
   Also there are certain assumptions in this scenario about what has to
   be authenticated.  I assume that the end-user is trying to get a certificate
   of authenticy from the printer and that the printer is only authenticating
   that the payment is OK. The printer does not need to know who the person is
   for allowing later cancellation of the job.

Section 8.11:  This stated scenario and accompanying example don't seem right.
   The scenario talks about authentication and yet the data is encrypted.  
   From the statement of the problem, the client should send the data in 
   clear form and then also send some password/userid information.  Depending
   on the protocol and client knowledge, the password/userid might accompany
   the print request or it might be separate. In HTTP, it would likely be separate.
   I would expect for this case to see either basic password or digest password.
   There is no need to get a secret key for all this.

   I think that this scenario is attempting to cover the simple authentication
   case that current printer systems handle. Currently it does not.

Section 8.12: This should just specify that a user submits authentication and
   it is rejected.

Section 8.13: I think that we all agreed in the protocol meeting that the protocol
   doesn't limit the length of jobs.  Therefore the print request and response
   look the same for a 1K and 1Gig job. What we did recognize, is that some clients
   may want to get a job-identifier back before the entire job has been transmitted.
   That implies a print request can be fragmented into start print request, 
   continue print request and end print request, but a client could send a 1K job
   via this mechanism.

   So, the question is, what is the requirement here? Given that a print request
   can submit as large a job as we wish, why does a client need a job-id before
   a job has been transmitted?  What is the use of any intermediate results?
   Do we really expect that failure of an intermediate means anything but the
   job was aborted, the same as the whole print request failing at the same point?

Section 8.14: I think that this scenario is unrealistic. If the printer jams and
   runs out of space for any more of the job, then the client should hang on 
   a write operation until the jam is cleared.  If someone hits reset on the
   printer, then I would expect the print request to end with a job aborted status.
   Likewise, if some one kills the transmission from the client side, I would 
   expect the printer to abort the job.

   If this scenario is changed to the RIP encountered a fatal error, then this
   scenario is OK, but it doesn't need all the intermediate parts of the operation.
   It is sufficient to say that the response came back before the printer received
   all the job data.

Section 8.15:  Scenario is OK, but the transmissions should be changed to a single
   request and response.

Section 8.16: There should be a statement to the effect that the referenced file
   must be publicly accessible, otherwise there are lots of security issues.

Section 8.17: There is no need for this scenario. At the protocol level, the
   document is one long stream, and a program reads it buffer by buffer.

Section 8.18: This section should omit any reference to long jobs. It should just
   be pull with errors.

Section 8.21: There is a missing scenario, namely where the client requests all
   attributes of a group, not knowing what new printer specific attributes might
   be in such a group.

Section 8.23: There needs to another scenario "get the status of jobs on printer X".  
   Some printers give all such jobs and others give only those owned by the
   user.  We can support "get the status of jobs on printer X" with no authentication,
   but not "get my jobs". There are still issues of authentication with the first
   case if some attribute values are accessible to a job owner only.

Section 8.27: There should be some mention of authentication here.  A person
   should not be able to cancel a job that is not his job.

Page 55: Is there any reason why the print request is broken into pieces?

Page 58: I think it is important to state that the fetching of printer attributes
   would not be done by today's pc drivers. Rather this is how future systems
   might do this.

Page 59: Again, get rid of the multiple parts of the print request to simplify
   things.

Section 8.30: As I said previously, I don't think that authentication is going on
   in the sense of verifying the identity. Rather it is verifying the availabilty
   of payment. For cancel job there are reasons to verify that the person cancelling
   is the same as the person submitting the job.

Page 63: Again, get rid of the multiple parts of the print request to simplify
   things.

---

From: JK Martin <[email-masked]>
Date: Tue, 11 Mar 1997 21:28:04 -0500 (EST)

Wow.  And these items represent YOUR list of issues to date...for just
the Requirements document?

Given the recent Star Wars craze, the old Hans Solo phrase of:

	"I'm getting a real bad feeling about this..."

comes to mind.

I think part of the reason the IPP effort is getting so deep is
due to the fact that we seem to be trying to create a "one size
fits all" solution that encompasses both printing AND spooling.
(We've run into this very same quagmire in the Job Monitoring MIB,
by the way.)

Could it be that the path to reasonable timeliness is to only
bite off the printing aspect without dealing with spooling?

Or do most folks think that we MUST deal with spooling when
trying to support printing, that the two must remain inseparable?

	...jay

---

From: Patrick Powell <[email-masked]>
Date: Wed, 12 Mar 1997 07:07:25 -0800 (PST)

# Or do most folks think that we MUST deal with spooling when
# trying to support printing, that the two must remain inseparable?

I have spent a fair amount of time thinking about your comment,
and I think you are overly pessimistic here.  I think that
most of the Requirements scenarios are illustrative, rather than
mandatory,  and not meant to force on a specific action.

There is a desire to divide up the protocol into 'printer' and
'management' functions.  However, by removing management OBJECTS like
queues,  databases, etc., from the model,  this leads to conceptual
difficulties when trying to figure out how to deal with printers
without dealing with the fact that there is a queue (i.e. - maximum
length 1, perhaps, mind you) in the printer,  and that there is a
database (implicit perhaps) in the printer about what functionality it
supports.

I feel that by putting the various items into the model,  and
addressing the operations on the queue and/or database in the
same way as the printer,  then things will become clearer.

For example,  I feel categorically that the setting up and modification
of the database is NOT part of the IPP standard.  This is an
out of band issue,  and should not be addressed in the standard,
nor should the behaviour of the printer be addressed during
updates,  etc.

On the other hand,  I feel that basic queue management functions,
such as restriction of submission of jobs by some criteria
SHOULD be part of the standard;  the implementation of this
should NOT be part of the standard.  This is currently the way
the MODEL document words things,  and I like this concept.

Now,  before everybody starts saying that this has been discussed
repeatedly,  and that everybody agrees that this is only meant
to handle printers,  you have embedded all of the concepts of a
general spooler in your printer REQ document.

Patrick Powell