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