IPP Mail Archive: Re: RE: IPP> Identifying jobs in requests

Re: RE: IPP> Identifying jobs in requests

Carl Kugler (kugler@us.ibm.com)
4 Jun 1998 17:02:53 -0000

Peter Michalek wrote:
...
>
> ** The following operations take job as the target of the operation
> 3.3.1.1 Send-Document Request
> 3.3.3.1 Cancel-Job Request
> 3.3.4.1 Get-Job-Attributes Request
> Target:
> Either (1) the "printer-uri" plus "job-id" or (2) the "job-uri"
> operation attribute(s) which define the target for this operation
> as described in section 3.1.3.
>
>
> ** The following operations take printer as the target of the operation
> 3.2.1.1 Print-Job Request
> 3.2.4 Create-Job Operation
> 3.2.5.1 Get-Printer-Attributes Request
> 3.2.6.1 Get-Jobs Request ......................................44
>
> Target:
> The "printer-uri" operation attribute which is the target for
> this operation as described in section 3.1.3.
>
>
> ** The protocol document states this about how HTTP is used to address a job
> target in 3.9:
> (iii)
> . "job-uri": When the target is a job and the transport is HTTP or
> HTTPS (for TLS), the target job-uri of each operation in the IPP
> model document SHALL be an operation attribute called "job-uri" and
> it SHALL also be specified outside of the operation layer as the
> request-URI on the Request-Line at the HTTP level.
>
> ** This means that for all jobs, the HTTP server serving IPP will have to
> generate CGIs or similar entities for each job in the queue or otherwise
> processed.

Is that really true? Suppose your Printer is implemented as a CGI program called /cgi-bin/IPPPrinter. Couldn't your job-uris take the form of

http://host.domain/cgi-bin/IPPPrinter/1159
http://host.domain/cgi-bin/IPPPrinter/1042

etc? That way, the web server dispatches the same script regardless of whether the Request-URI addresses a Printer or a Job. The script can get the job-id part of the URI from PATH_INFO. Another possibility would be to generate job-uris that look like

http://host.domain/cgi-bin/IPPPrinter?job-id=1159
http://host.domain/cgi-bin/IPPPrinter?job-id=1042

or even

http://host.domain/cgi-bin/IPPPrinter#1159
http://host.domain/cgi-bin/IPPPrinter#1042

The HTTP server serving IPP has to generate unique URIs for each job in the queue or otherwise processed, but not necessarily new CGIs.

>
> I think this is not practical and it provides justification for having
> the target attribute for job-uri in the IPP layer as well.
> For consistency, it would be good to do the same for printer-uri and
> modify (iii) above to reflect that.
>
> Also, in the line from the spec above:
> Target:
> Either (1) the "printer-uri" plus "job-id" or (2) the "job-uri"
>
> (1) can't be translated into a HTTP request line which specifies only
> one target, as (2) provides.

I agree that in some implementations, "job-id" will need to be specified as an IPP operation attribute.

>
> Perhaps target of the operations should be only printers and job-id would
> be considered an argument of the method invoked, or an operation
> attribute (e.g. cancel job).

Works for me. You could also use relative job-uris with this approach.

>
> This would provide practical multiplexing within the module that
> processes IPP requests, be
> it CGI, servlet, NSAPI or ISAPI extension, where one printer would
> typically be served by
> one module for each security scheme.
>
> Peter
>
>
>
>
Carl