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

Robert Herriot Robert.Herriot at Eng.Sun.COM
Tue Mar 11 21:06:20 EST 1997

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

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

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

More information about the Ipp mailing list