IPP Mail Archive: [Fwd: IPP> ADM - Minutes from the IPP Meeting in Toronto on August 19-20, 19]

[Fwd: IPP> ADM - Minutes from the IPP Meeting in Toronto on August 19-20, 19]

Carl Kugler (kugler@us.ibm.com)
Thu, 17 Sep 1998 09:38:02 -0600

Carl Kugler wrote:
>=20
> In reply to http://www.pwg.org/hypermail/ipp/1238.html
>=20
> > Question The URI in the HTTP layer is either relative or absolut=
e and is used by the HTTP server to route the HTTP request to the correct=
resource relative to that HTTP server. This "resource" is either an IPP=
Printer or a Job, right?
> >
> > The HTTP server need not be aware of the URI within the operation req=
uest. Once the HTTP server resource begins to process the HTTP request, i=
t might get the reference to the appropriate IPP Printer object from eith=
er the HTTP URI (using to the context of the HTTP server for relative URL=
s) or from the URI within the operation request; the choice is up to the=
implementation.
> >
> > Once the Printer or Job ("the HTTP server resource") has begun to pro=
cess the job, why would it need a reference to an appropriate IPP Printer=
object?
> >
> > Implementation question: the server is REQUIRED to check for the pre=
sence of target URI operation attributes in every request (and respond wi=
th client-error-bad-request if not found) but is otherwise free to ignore=
target op. atts.? The Request-URI and target URLs might not be literally=
identical although they MUST both reference the same IPP object; however=
the server isn't required to verify this?
> >
> > Carl Kugler
>=20
> > Question 2 -- [Carl-Uno noted that the Discussion in the document is =
not relevant to the Question. The Discussion will be removed, or atttache=
d to a different Question (see below.)] Answer: Yes, the =93resource=94 i=
s either an IPP Printer or a Job. However, the group was unable to addres=
s the remaining parts of the Question. They will request Carl Kugler to p=
rovide further clarification. It is (at least) unclear what assumptions a=
re being made.
>=20
> Okay, let me try to clarify.

Oops! I forgot to list my assumptions. Maybe my problem lies in a
flawed assumption. Let me try again from the beginning. Assumptions:

1) IPP attributes are only meaninful to IPP Objects.
2) There are only two classes of IPP Object: Printer and Job
3) The "printer-uri" IPP operation attribute is only relevant in
operations directed at Printer objects.

I'm trying to understand how to implement this specification from PRO:
> The HTTP server need not be aware of the URI within the operation
request. Once the HTTP server resource begins to process the HTTP
request, it might get the reference to the appropriate IPP Printer
object from either the HTTP URI (using to the context of the HTTP server
for relative URLs) or from the URI within the operation request; the
choice is up to the implementation.

Since the sentence implies that the "HTTP server resource" can get the
"printer-uri" IPP attribute, by 1) I conclude that it must be an IPP
Object. By 2) I conclude that it must be a Printer or Job. By 3) I
conclude that it must be an IPP Printer object. So the last sentence
can be reworded, without changing its meaning, as:

> Once the IPP Printer object begins to process the HTTP request, it
might get the reference to the appropriate IPP Printer object from
either the HTTP URI (using to the context of the HTTP server for
relative URLs) or from the URI within the operation request; the choice
is up to the implementation.

What is the "appropriate IPP Printer Object" that the Printer is getting
a reference to, and why is it getting it? What must the Printer do with
the reference to the approporiate IPP Printer Object once it has gotten
it?

-Carl