Carl,
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 at us.ibm.com> 09/17 9:38 AM >>>
Carl Kugler wrote:
>> In reply to http://www.pwg.org/hypermail/ipp/1238.html>> > 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
>> > 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.
>> 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