To: HPARRA@novell.com
cc:
From: Carl Kugler/Boulder/IBM @ IBMUS
Subject: Re: [Fwd: IPP> ADM - Minutes from the IPP Meeting in Toronto
I was basing my assumption on these words from MOD:
For Job operations, the operation is directed at either:
- The Job object itself using the Job object's URI. In this case, the client identifies the target object by supplying the correct URI in the "job-uri (uri)" operation attribute.
- The Printer object that created the Job object using both the Printer objects URI and the Job object's Job ID. Since the Printer object that created the Job object generated the Job ID, it MUST be able to correctly associate the client supplied Job ID
with the correct Job object. The client supplies the Printer object's URI in the "printer-uri (uri)" operation attribute and the Job object's Job ID in the "job-id (integer(1:MAX))" operation attribute.
I interpret this as saying that a Job operation is directed at a Printer object when the target is specified using "printer-uri" and "job-id" attributes.
If the target is specified using the "job-uri" attribute, the operation is directed to the job itself.
-Carl
Please respond to HPARRA@novell.com
To: Carl Kugler/Boulder/IBM@ibmus, ipp@pwg.org
cc:
Subject: Re: [Fwd: IPP> ADM - Minutes from the IPP Meeting in Toronto
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@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 contex
t 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 a
nd 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. Howeve
r, 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
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
>
>
>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4496
-- Free e-mail group hosting at http://www.eGroups.com/