Roger,
Outstanding effort. The presentation technique is great. I hope we can
standardize on your format for the Scenarios effort.
On the "Submitting a Print Job" description page (p.8), it is stated that
the protocol must support both pushing and pulling client print data. In
this section does "pulling print data" imply the client is specifying a URL
(instead of content) in the job submission request? If so, then we might
have more flexibility in mapping printing protocols to IPP if we instead
state:
The protocol must support these sources of client print data
- print data is a file
- print data is being generated on the fly by an application
- print data is referenced by a URL (or list of URLs?)
How the server gets the print data represented by the URL could then
be placed outside the scope of IPP v1.0. (Sorry, but I might be implying
URI instead of URL; I never could get those two straight.)
In Scenario #1 of "Submitting a Print Job" (p.9) it looks as if this
scenario involves a single transaction specifying multiple requests:
- job submission (with job parameters, including notification method)
- printer status
I'm not sure if we've discussed this before, but has it been decided
that a single IPP transaction (ie, request/response) can contain more
than one type of request? (Inasmuch that either of the two request
types above could have been separately transacted with the same relative
results.)
In the Scenario #2 of that set (p.10), should the "Print file" protocol
line perhaps say "Send file" to reduce the semantics? Or is something
more complex going on here, other than a simple file transfer?
In Scenario #1 of the "Getting Status" series (p.12), the returned job
status information shows:
Current-job-status: printing
Should we also consider this kind of situation:
Current-job-status: printing
Current-printer-status: out of paper
That is, should the scope of IPP include addressing the correlation of
status from related components (in this case, the queue and the printer)
to provide a greater potential for more accurate overall status? Or are
we taking the approach where it is left as an "exercise for the reader"
(er, "product opportunity") to integrate status of these components?
(I'm not a preference at this time, just asking the question. ;-)
In Scenario #2 of this series (p.13), I think I understand the idea about
sending the values as a series, where the first value is the default. But
I'm not sure about:
copies = 1, 2, 3
This implies a default copy count of 1 (right?), but does it also imply
that a client can only specify no more than 3 copies of the job? I like
the idea of the "first-value-is-the-default" concept, but it might mean
we have to come up with a range specification, with possible "infinite"
value specs.
In the "Listing all Print Jobs" description (p.16), I think I got lost.
The great abbreviated prose was replaced by pseudo-HTTP, and somehow I
missed exactly what was going on (in terms of requirements, not in terms
of implementation).
Also on that page, while I realize the returned values are only examples,
this line made me wonder:
Job-identifier: 0035
If we end up with a URL format for a job identifier that looks something
like this:
http://abc.domain.com/printer/laser1/jobs/0035
Then might we expect problems if the job identifier is verbally discussed
as "job 35 on printer laser1", in which someone might accidentally enter:
http://abc.domain.com/printer/laser1/jobs/35
That is, "35" is entered instead of "0035". If instead this kind of URL
format is defined:
http://abc.domain.com/printer/laser1/jobs?35
then the "jobs" URL could do some useful transformation (ie, 00035 -> 35)
if it were a CGI program. This may not be the time to discuss this kind
of situation, but I just wanted to flag the situation as it passed by.
In general, seeing these various scenarios makes me wonder whether we
shouldn't be more explicit in our Model in denoting the differences
between a "printer" and a "spooler" (or other non-printer components
of the printing system); that is, make it clear that an implementation
containing a "printer" may also contain a spooler (or spoolers), but
that the function of a "printer" does not necessarily imply the function
of a "spooler". (This is a fundamental aspect of the DPA model, no?)
Or perhaps did I misunderstand the level of abstraction for these scenarios?
Again, really great effort, Roger. You've done a fine job of collecting
some of the most challenging aspects of the IPP problem domain in one
clean set of mini-documents.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------