Classification:
Prologue:
Epilogue:
I have been thinking about this subject quite a bit and have been discussing it
with Steve Gerbert here, who is working on prototyping some of this stuff. Here
are some observations and thoughts -- any comments?
1) Based on my investigation into cgi scripts, it would appear that our URLs
should be of the form
http://some.domain.com/ipp.exe/printer-1.
the phrase ipp.exe identifies the cgi application that will handle this
request, and would be defined in the standard to always be there. The phrase
printer-1 would identify the Printer to which this request is to be applied.
The server will pass the phrase printer-1 to the cgi application as an
environment variable. This is not strictly valid use of http, as this field is
normally defined as a pathname, but it would work and seems to be the only
option with the PUT method.
2) I'd suggest that as an abstraction, a Printer (capital P) contains the
characteristics of the output device, spooling/scheduling characteristics, some
set of administrative job defaults, and some set of policy attributes. At this
stage we don't know how the defaults and policy attributes get established. We
may address this when we add administrative functions, or we may leave it as an
implementation exercise -- maybe this is where each company adds their unique
value.
In any case, it is this collection of things, including the job defaults, that
I myself would think of as THE Printer. Now there may be many of these
associated with a single output device, but when I look in the directory or
submit a print job or request status of a Printer, it is this collection or
abstraction that I want to see. Of course, an output device may have no job
defaults specified or only one set of defaults specified, in which case Printer
= ouptut device from that point of view. Given this, then "printer-1" in the
previous example always points to a Printer (capital P -- including job
defaults). The result of this stream of consciousness is that I don't think
that there is such an addressable thing as a job-template. That is, I can't spe
cifiy a job template in a URL, or request its attributes.
3) Given all of the above, what does it mean to do a getAttributes" operation
on a Printer. What I'd like to propose is the following idea. When I direct a
getAttributes request to a Printer with no attribute list specified, the
Printer synthesizes a response which we might in fact now think of as a
job-template. That is, the Printer takes the characteristics of the output
device, overlays that with policy attributes and defaults, and sends this back
to the client. In the simple case the client now only needs to present this to
the end user to fill in the blanks or change defaults, and send this back to
the Printer in the print request. An alternative would be to add a
getJobTemplate operation, but getAttributes seems to work just fine.
We think that this simplifies the model significantly and seems to provide the
right function in a straightforward, easy to implement way. Thoughts??????