IPP Mail Archive: Re: [Fwd: IPP> ADM - Minutes from the IPP Meeting in Toronto

Re: [Fwd: IPP> ADM - Minutes from the IPP Meeting in Toronto

Hugo Parra (HPARRA@novell.com)
Thu, 17 Sep 1998 14:57:51 -0600

Carl,
=20
Assumption 3 (The "printer-uri" IPP operation attribute is only relevant =
in
operations directed at Printer objects.) is invalid. Operations directed =
at Job objects can specify (1) the job-uri, or (2) the printer-uri and =
job-id. I'm not sure this affects your argument, however.

-Hugo

>>> Carl Kugler <kugler@us.ibm.com> 09/17 9:38 AM >>>
Carl Kugler wrote:
>=20
> In reply to http://www.pwg.org/hypermail/ipp/1238.html=20
>=20
> > Question The URI in the HTTP layer is either relative or absolute =
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 =
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.
> >
> > Once the Printer or Job ("the HTTP server resource") has begun to =
process the job, why would it need a reference to an appropriate IPP =
Printer object?
> >
> > Implementation question: the server is REQUIRED to check for the =
presence of target URI operation attributes in every request (and respond =
with 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 atttached =
to a different Question (see below.)] Answer: Yes, the *resource* is =
either an IPP Printer or a Job. However, the group was unable to address =
the remaining parts of the Question. They will request Carl Kugler to =
provide further clarification. It is (at least) unclear what assumptions =
are 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