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

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

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

Paul Moore (paulmo@microsoft.com)
Wed, 10 Jun 1998 09:06:41 -0700

> No, the URI is actually a URL that is to be interpreted according to
> "standard" rules for interpreting URLs (not sure if there is a "formal"
> standard for this). These resource identifiers are not opaque to clients.
> This does not mean that we are NOT transport independent, it only means we
> are identifying resources that must be accessed via the transport (scheme)
> that is specified in the URL.
[Paul Moore] not so - for at least 2 reasons.

1. In some transports the server cannot know the adressing scheme of
the client and so cannot form an adress that makes sense for the client. A
URI is meant to be Universal (hence the name) - even if a server can form a
URI that makes sense in the addressing scheme of the original client, what
happens if this is forwarded to another client? Example - in a 1284
connected environment what should the URI look like (ipp:/lpt1/jobx ?), how
does the server know which lpt port number to use.

2. I cannot forward an IPP packet containing a URI to another system
that is not part of the same homogeneous address space as the original
client and server. I have to crack every packet , find all the URIs and
change them. However I do not know HOW to change them because we have
avoided making rules about the formation of URI (they are supposed to be
implementation specific), without the knowledge of which bits mean what in
the URI I cannot know how to change them from one transport to another