IPP Mail Archive: Re: IPP> ADM - IPP Minutes posted: questions about 3.1.11 an

Re: IPP> ADM - IPP Minutes posted: questions about 3.1.11 an

Carl Kugler (kugler@us.ibm.com)
Fri, 29 May 1998 12:08:45 -0400

> 3.1.11 Reaffirmed that target attributes must be supplied in the requ=
est
redundantly
> We agreed that target attributes should be redundantly carried inside=
the IPP
operation as well as externally in the HTTP request header.
> This redundancy is necessary to keep the IPP MIME media type
transport-independent.
> There was debate over the architectural soundness of this proposal, a=
s it
would prevent simple re-routing of the job to a new target based on inf=
ormation
from the request header.
> Instead, to re-route, the embedded target must be learned from examin=
ation of
the IPP stream.

I don't understand the re-route mechanism.
Is HTTP REDIRECT involved?
Is an HTTP proxy required to open up the application/ipp body and rewri=
te it?
Could someone please give some re-route scenarios?

> It also complicates test.
> Following discussion, there was strong opinion not to change anything=
so the
decision to adopt this change (which had already been made - target att=
ributes
inside the operation) stands as is and test tools must deal with the si=
tuation
as required.
>
> 3.1.12 Clarified that the target URI are absolute form
> Per above, suppose we have printer URI inside the operation, but also=
have it
in the HTTP request header mapping.
> There is the issue of Absolute vs. Relative addressing of the target.=

> Internal to the IPP operation, only Absolute URL's apply.

ALL internal URIs are absolute?

> But, in the HTTP header, it might be Relative.

MUST be, unless you're talking to an HTTP proxy server.

> We reiterated that the internal URI is mandatory but the server does =
not need
to check it for routing.
> In fact, the HTTP request header URI, if present, takes precedence.
> The internal URI should reference the same URI as the one in the HTTP=
header
(should not be garbage).

What is the rationale for this? (Esp. given that the server does not ne=
ed to
check it for routing and that the HTTP request URI takes precedence.)
Could you elaborate on what's required to satisfy this?
Suppose the two URIs effectively reference the same resource but they a=
re
significantly different (say, as the result of an HTTP redirect)?
Leniency on this requirement would facilitate testing with binary trace=
files.

> The external URI may be Relative.

MUST be, unless you're talking to an HTTP proxy server.

=