1) From a design perspective, it breaks the paradigm of invoking an ope=
ration
(IPP Operation) on a specified object (Target), because the object refe=
rence is
now part of the operation. This architectural impurity manifests itsel=
f as:
2) A practical problem: our testing methodology is broken, because bin=
ary IPP
trace files will have to embed Target URIs. We will no longer be able =
to take
an existing trace file and try it on different Printers (and so far tha=
t has
been a useful capability).
-Carl
owner-ipp@pwg.org on 05/11/98 04:44:30 PM
Please respond to owner-ipp@pwg.org
To: ipp@pwg.org
cc:
Subject: IPP> MOD & PRO - "printer-uri" or "job-uri" in Operation Att
The IPP/1.0 Protocol document examples do not show the "printer-uri" or=
"job-uri" (or "printer-uri" and "job-id") as being one (two) of the
Operation attributes in each request.
The Model document is quite clear about the "Target" for each request
being one or two Operation attributes. See section 3.1.3.
I belive that we agreed at the end that in order to make our protocol
independent of the transport, that the "target" of the request would
be passed in the Operation Attribute group (as well as being in the
HTTP/1.1 header).
So we should add the "printer-uri", "job-uri", or "printer-uri"/"job-id=
"
attributes to the request examples.
ISSUE: where in the Operation attribute group, should these
attributes go? We have already agreed that the "attributes-charset"
and "attributes-natural-language" SHALL come first, in that order, sinc=
e
the charset is needed in order to be able to understand the subsequent
attributes in the Operation Attributes group that have values that are
text or name. And both attributes MUST be passed in every request and
response.
In talking with Bob Herriot, we suggest that the target come immediatel=
y
after the "attributes-charset" and "attributes-natural-language attribu=
tes.
Thus the next attribute SHALL be: "printer-uri" or "job-uri" or
the next two attributes SHALL be: "printer-uri" and "job-id", depending=
on the operation.
So the Model document needs to be updated to specify the order of the
above Operation attributes, since the order applies to all protocol
mappings.
Ok?
Tom
=