What URL components are typically rewritten by proxies (or other
intermediaries)?
Randy
-----Original Message-----
From: Carl Kugler [SMTP:kugler@us.ibm.com]
Sent: Thursday, June 04, 1998 12:27 PM
To: ipp@pwg.org
Subject: Re: IPP> Identifying jobs in requests
> It seem to me that the fundamental question comes down
to - should
> the IPP protocol form, transmit and use information that is
specific to the
> underlying transport.
>
> We have chosen to use URI as our way of identifying
endpoints.
Could you define "endpoint" in this context? Is it equivalent
to an IPP "target"? Or are you using the term in the TCP sense?
>The
> assumptions we make about these URIs (there actual syntax is
irrelevant)
> are:-
> a) an agent knows how to form them
> b) the only thing an agent may do with a URI it receives
to it is to
> pass it to its underlying transport. This means that the
creator of the URI
> MUST use the same URI forming convention as that which will be
used by the
> receivers transport stack (ie. this is not a private issue for
a given
> implementation). It also means that the receiver may not look
at the URI to
> infer any deeper meaning (because that is a private issue for
the sending
> implementation).
> This last restriction made us invent job-id. We moved to
explicitly
> stating in IPP the way of identifying an endpoint.
> The real problem is that we end up with leakage from the
transport
> up into the IPP layer. I cannot blindly forward requests from
> IPP-on-protocolX to IPP-on-protocolY. I have to find all the
URIs and change
> them on the fly.
> There is another problem that assumpion b causes. It
assumes that a
> printer knows how to form an address (URI) that makes sense in
the clients
> transport stack. This is true for HTTP but not true (or
certainly
> non-trivial) for other transports.
>
> I would propose that we use an adressing scheme that
corresponds to
> the transport endpoint only. We then specifiy in IPP the ways
of identifying
> the logical object that we wish to talk to (printer-ID,
Job-ID,...).
>
Or you could invert this, and put the target addressing outside
the IPP payload. Then you can forward requests and/or rewrite target
addresses without ever opening the "envelop", to use Scott's postal
analogy. For this to work, any internal target identifiers would have
to be relative (like job-id).
It seems to me that your scheme would require the transport
endpoint to be some kind of IPP Server that could route requests to
Printers based on embedded printer-ID. Then you've added another layer
of indirection to the IPP model.