My responses to Scott's comments follow:
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/22/97 02:37
PM ---------------------------
ipp-owner @ pwg.org
01/22/97 01:06 PM
To: ipp @ pwg.org@internet
cc:
Subject: IPP> REQ - scenario issues
pg 4
"but the client only sees one device" Make sure that they know this is a
logical device or an abstraction in the IPP model of "one device" not that
they can only see one of the two and never print on the second.
answer: I'll fix this so it is clear.
pg 5 1.0
One of the bullets on the response is "capabilites" Do we care at this
high level scenario effort to enumerate the possible capabilities or is the
requirement simply to say "capabilities" and then automatically analyze
whatever comes back
answer: cpabilities here was meant to be things like PDL, media-supported,
etc. I didn't intend in this list to enumerate them. The other things
listed on that page were additional things that I thought were required.
One of the paragraphs says "enough information to make a choice". For
the IPP directory work we are going to explicitly define what "enough" is.
Is this requirement asking for an open ended "enough" or it just hasn't
taken the trouble at this point to enumerate what "enough" really means.
I propose that the set of attributes in the name service section of the
current I-D is "enough"!
answer: I don't think that the current I-D is complete, that's why I
specifically called out the need to have "enough" information available
from the name service. Example: Driver location.
pg 9, 2.0
The last paragraph is so vague that it shows how hard it is to scope this
problem. If we dive into this are we going to enumerate the what "many'
and "different" really mean? A printing standard that works for just one
desktop OS will not be a good thing.
answer: The description has to be flexible to allow declaration of driver
versions, OS's supported, etc. I like Bob Sproulls suggestion to perhaps
add an installation string, which could provide information such as .inf
file required or whatever. The content of this string could be
installation/os specific.
pg 10, 2.1
One of the scenarios might be to ask the name service not the Printer
about this driver info. Maybe the Printer just doesn't know or has been
over ridden by an admin. The name service is where to keep this or if
not that some other "driver location service" given make and model.
answer: Scenario 1.2 does show this coming from the name server.
pg.12 3.1
This shows a "spool id" being returned. Why isn't this called a "job id"?
Also, we know that we haven't "picked a transport yet", but haven't we
really decided that this Printers and Jobs are going to definitely be named
with URLs? I think so. We just haven't picked the scheme of the URL yet
(http:// vs ipp:// vs other_new_lite:// vs. etc). So we ought to show
URLs in these scenarios and thus show a URL for the Job going back in
the response.
answer: I will change spool-id to job-id. Even though we will use
URLs, I'd prefer to keep the scenarios completely free of protocol.
pg 13. 3.2
On the discussion list, there was talk of async operations and the risk of
lost jobs or multiple jobs if the end-user is waiting for the job to actuall
print before the response comes back to a submit request That is, I
remembe that we decided our operation model was to submit a job
(request) , and then immediately confirmation comes back (response)
that it was submitted and then all status comes back later either through
queries or async events. This scenario currently shows a bunch of
status coming back in the response to the submit. I am thinking that in
many cases that the status is pretty limited at submit time and that most
status is "generated" later as real work is done.
answer: I think this is covered in the end-to-end scenarios.
3.4
In comparing 3.4 and 3.5, 3.4 has security built right into the operation. It
doesn't show it, but in 3.5 once a session takes place of "mutual
authentication" then the end user is left with a "credential" to send along
with the request which the server side processes to make sure that the
end user has the rights to perform the operation. I propose that all
security takes place "outside" of IPP operations. Then we just assume
that in each operatoin the end-user sends in a credential as part of the
IPP operation. This credential is open ended: it could have been
generated from a 3rd party key server, from a conversatio with the
actual Printer using some security protocol, or it could just be a
password that the end-user knows and sends along as the "credential"
or it could be NULL and the server is set to not have access control
checks and allows operations with NULL credentials. In other words,
lets make sure that we do not build right into IPP a security mechanism,
but if we have to roll or own, make it modular so that it can be swapped
out at any time.
answer: I agree, but this is a model/protocol issue.
3.6 and 3.7
"using a downloaded driver". Shouldn't this just be any driver (whether it
was auto downloaded, existed before, installed manually and the
configured to point to a network port, etc.) not just a "downloaded"
driver?
answer: Yes. I'll fix this.
3.6
I would tend to draw the multiple sends as multiple arrows going from the
end user to the printer (ie allow for a new operation which is just a "here
is some more data" for a previous submit).
answer: I intentionally did not show this because I did not want to imply
any particular protocol. Doesn't this happen at the TCP level anyway
(that is, ther are multiple tranmissions with responses on the wire)?
HTTP 1.1 has a "continue" header which I don't fully understand, which
we might want to use here.
7.1
In current desktop printing models, the printer driver has no mechanism
for talking to the "ipp driver" directly. It simply writes to a fairly simple
port interface (single channel, single data stream, just PDL, no control
data) which then is serviced by a local port driver or a network driver
such as an IPP driver. So this scenario better include current printing
limitations as well as "future, wish it were so" situations. In other words
another version of 7.1 becomes:
-----------------------------
Driver puts up dialog
End user makes choices
Driver formats the document into some PDL
Driver writes document to "port" interface
IPP driver behind "port" interface has no attributes, just a PDL stream
IPP driver submits job with almost no attribute info
IPP driver adds new job to list of known jobs
Client selects job and asks for status
.... (and on as before)
-----------------------------
The big difference is that current drivers are not programmed to query
the printer directly or the "port" interface is not set up to accept
"out-of-pd-stream" attributes. So the richness of having modifiable job
"attributes" is lost. Same is true for 7.2
answer: I can add this end-to end scenario.