At 09:06 AM 6/10/98 -0700, Paul Moore wrote:
>> 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.
In practical application, the server would never return a resource
identifier that specified a transport to which the client had not already
used to contact the server. And the forwarding scenario isn't realistic,
and also outside the scope of IPP.
>> 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
This isn't supported by IPP either; this functionality would be some type
of gateway application that would have to administratively configured. The
way we have it defined now carves out middle 80% functionality we wanted to
achieve.
Randy
>