IPP Mail Archive: Re: RE: IPP> Identifying jobs in requests
Re: RE: IPP> Identifying jobs in requests
Carl Kugler (
kugler@us.ibm.com)
3 Jun 1998 18:37:31 -0000
>
> 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.