"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.
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 capabiliites or is the
requirement simply to say "capabiliites" and then automatically analyze
whatever comes back
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"!
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.
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.
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
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.
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.
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"
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).
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
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com