Subject: Re: RE: IPP> Identifying jobs in requests

From: "Peter Michalek" <[email-masked]>
Date: Wed, 3 Jun 1998 14:49:37 -0700

-----Original Message-----
From: Carl Kugler <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, June 03, 1998 11:46 AM
Subject: Re: RE: IPP> Identifying jobs in requests

>>
>> It's a question of layering, and not a question of actual transport
>> capability. In our model we have a much more serious case of overlap
>> between transport and application addressing than do most other
>> applications. WEBDAV doesn't have to worry about this since they do not
>> have to be transport-independent. Most of the time, there is a
>> multiplexing/demultiplexing step involved when a transport layer has to
>> demultiplex something and send it to the right endpoint. In our case,
>> there is a one-to-one relationship between transport identifier (HTTP
>> URL) and IPP URL. Not that there has to be, its just that's the scenario
>> that everyone seems to be worried about. If you carved up a URI wherein
>> some portion was transport and some portion was IPP, then it might be a
>> little easier to deal with, in that it is much less likely that a
>> correctly chosen IPP URI-portion would be rewritten or modified in any
>> way from sender to receiver.
>>
>> Randy
>>
>
>Okay, to carve up URIs by layer, we should use Relative identifiers.  So
the Request-URI identifies a Server within (relative to) a Host,
>the "printer-uri" identifies a Printer within a Server,
>the "job-uri" identifies a Job within a Printer.
>
>All are Relative URIs defined within the context of the encapsulating
entity.  There can't be overlap conflicts.

** 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.

   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.

   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).

   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

---

From: "Carl Kugler" <[email-masked]>
Date: 4 Jun 1998 17:02:53 -0000

Peter Michalek wrote:
...
>    generate CGIs or similar entities for each job in the queue or otherwise

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.

>    one target, as (2) provides.

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

> attribute (e.g. cancel job).

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

>    one module for each security scheme.
Carl