Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
Bob, I think we need to view the scenarios as illustrative of the functions and
operations required ... from an end-user's point of view. They are not meant to
be exhaustive, nor do I think it is possible in a set of scenarios to cover in
detail every combination of operations and conditions which might occur. I
guess we need to ask "is a new scenario critical to understanding some element
that must be included in the protocol, or can it be inferred or handled in text
as a variation of an existing scenario?" Responses to specific comments follow:
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/12/97 12:08
PM ---------------------------
.....snip ......
print request from windows with no attributes,
the Printer may default attributes except for
production attributes which are embedded in
the document data.
RKD>> You clearly mean today's versions of
RKD> WIndows, don't you? Is a new scenarion
RKD> critical to understanding?
print request from Unix with no attributes,
the Printer may default all attributes including
production attributes.
RKD> Is a new scenario critical to understanding?
RKD> If so, why not a scenario with production
RKD> attributes imbedded in the document data?
RKD> Surely an application on a unix system can
RKD> generate imbedded 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.
RKD> Is this a legacy printer? Otherwise why doesn't
RKD> it support production attributes. Isn't this
RKD> a conformance requirement?
The first two cases should at least be covered
in the context where a Printer sets defaults
for unspecified attributes.
RKD> This could easily be done by adding a few
RKD> words to the text of the existing scenarios
RKD. where appropriate.
There are also issue with regard to whether
an attribute expresses a requirement or
"best-effort". Perhaps there should be a
scenario discussing this.
RKD> I think the whole area of attribute
RKD> adornments is complex and confusing.
RKD> Perhaps a scenario or two would be helpful
RKD> but I'd prefer that you draft them since
RKD> you understand what you are trying to achieve
RKD> here better than I do.
Section 2.1.1 Is "inside the firewall" an
appropriate search criteria?
RKD> I think "in my domain" is useful, if that's
RKD> what's implied by inside the firewall.
... snip ...
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'.
RKD> I don't think that all printers can always determine
RKD> the format of the print data. Certainly we have
RKD> legacy printers that cannot. I've encountered that
RKD> problem many times.
... snip ...
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.
RKD> I blame this confusion on poor communication
RKD> on our part when we talk to one another. I can
RKD> recall a number of conversations where cancelling
RKD> a job was discussed in terms of job modification.
... snip ...
Section 3, bottom of page 11: Is this list of combinations
of case with firewalls useful? I don't think it is.
RKD> As we've discussed security issues it certainly makes
RKD> a difference when working within or across security
RKD> domains.
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.
RKD> Actually I disagree. From the user's perspective the
RKD> print operation should be viewed as a request to have
RKD> something PRINTED! Transporting the print job is an
RKD> interesting protocol issue, but the user probably
RKD> doesn't care about it unless it fails.
The operation should primarily report back that the job
was sucessfully transmitted or it wasn't.
RKD> I disagree.
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.
RKD> Can't parse the above sentence ...
When the print operation completes,
RKD> By "print operation completes", do you mean the
RKD> transmissison 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.
RKD> Oh, so it is okay to say that that the printer
RKD> started to print but failed!
... snip ...
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.
RKD> As in my response to Tom, I don't think that the
RKD> requirements document MUST precisely use the same
RKD> terminology as the model document. It is to meant
RKD> to show INTENT. The end user wants to know what's
RKD> going on with the printer. He doesn't care a hoot
RKD> what we call it or how it's expressed in the
RKD> protocol.
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.
RKD> From the end user's point of view is there any
RKD> difference? It seems that in both cases the
RKD> end user gets told "can't communicate with the
RKD> printer any more. In the gets notified case I might
RKD> get a little more information, but this just seems
RKD> a special case.
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.
RKD> I'd prefer to let the end user know that the printer
RKD> is not communicating and let him make the decision
RKD> to wait or not.
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.
RKD> Hard to parse the above sentence.
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.
RKD> The printer is autheticating who the user is.
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
RKD> I could certainly take encryption out of the
RKD> sceanrio if it is confusing, but I don't see
RKD> why it isn't a valid operation.
RKD> Why would you assume that someone would not
RKD> want to encrypt the data in this case?
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.
RKD> Unless I happen to use mutual authentication and
RKD> want to encrypt my print file. As stated in my
RKD> preface to these responses, I'm not trying to cover
RKD> every conceivable combination of things here. In the
RKD> case of security we could add 10-20 additional
RKD> sceanrios to cover all kinds of authetication
RKD> schemes, passwords, etc.
I think that this scenario is attempting to cover
the simple authentication case that current
printer systems handle. Currently it does not.
RKD> No, actually it was meant to show the use of
RKD> a strong authentication scheme, like SSL v3,
RKD> being used in an intranet environment.
Section 8.12: This should just specify that a
user submits authentication and it is rejected.
RKD> It could.
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?
RKD> As stated in the text for this scenario, it is
RKD> intended to illustrate the need for an application
RKD> or a print driver to be able to generate fragments
RKD> or segments, or whatever you want to call them, on
RKD> the fly without having to know the length of the
RKD> entire print job beforehand. This exactly models
RKD> the NT 5.0 operation that Babek described to us.
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?
RKD> Hmmm ... I thought we had agreed that some clients
RKD> would like to "start" the print job and know that
RKD> the operation (including the attributes) were valid
RKD> before sending the print data. Also I thought we
RKD> had agreed that some applications, like print drivers,
RKD> would use the intermediate result (the job URL) to
RKD> send the remaining fragments of data to.
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?
RKD> Maybe it depends on what the failure is.
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.
RKD> I guess we'll never agree on this one. When I use Windows
RKD> to submit a print job (which is what this scenario is
RKD> meant to cover, and the printer cannot take the data
RKD> because of a problem that I can fix (or ignore and
RKD> choose to print my job someplace else) I'd like to
RKD> know about it right now! I'd prefer not to get some
RKD> asynchronous message in my email two days later that
RKD> tells me that the printer was jammed (and later that
RKD> someone else fixed it).
RKD> I guess my philosophy is that you can always choose
RKD> not to use a feature of a protocol if you think
RKD> you don't need it, but it's very hard to add new
RKD> capabilities to a protocol (and all of the shipped
RKD> implementations) when you discover you need it later.
RKD> I guess I don't want to be the one to hang when the
RKD> first critical customer situation occurs where end
RKD> user;s complain because tyhey don't know what's going
RKD> on at their printer.
If someone hits reset on the printer, then I would
expect the print request to end with a job aborted status.
RKD> If they know enough to walk down to the printer and
RKD> reset it. Actually, I'd rather not have to walk that
RKD> far if I could abort the job from my office.
Likewise, if some one kills the transmission from the client
side, I would expect the printer to abort the job.
RKD> If we are sitting there waiting on a printer jam and
RKD> have no idea that the job is even hanging, how would
RKD> we know to abort the job?
... snip ...
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.
RKD> I agree
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.
RKD> I added this sceanrio at Carl-Uno's request.
RKD> If he agrees then I'll take it out.
Section 8.18: This section should omit any
reference to long jobs. It should just be pull with errors.
RKD> I don't think it does reference long jobs???
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.
RKD> Do we really need a new scenario?
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.
RKD> I'm confused. In discussions we've had I always thought
RKD> we agreed that we should ONLY report status of MY jobs.
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.
RKD> Probably would be a good idea.
Page 55: Is there any reason why the print request is broken into pieces?
RKD> It is being generated by a driver.
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.
RKD> Okay.
... snip ...