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