Subject: Re: IPP> MOD & PRO - "printer-uri" or "job-uri" in Operation

From: Carl Kugler <[email-masked]>
Date: Mon, 11 May 1998 19:33:53 -0400

Maybe it's too late to question whether or not the Target should go outside of
the operation layer as the request-URI on the Request-Line at the HTTP level
AND into the Operation Attributes, but I can think of a couple downsides:

1) From a design perspective, it breaks the paradigm of invoking an operation
(IPP Operation) on a specified object (Target), because the object reference is
now part of the operation.  This architectural impurity manifests itself as:

2) A practical problem:  our testing methodology is broken, because binary 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 that has
been a useful capability).

  -Carl

[email-masked] on 05/11/98 04:44:30 PM
Please respond to [email-masked]
To: [email-masked]
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, since
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 immediately
after the "attributes-charset" and "attributes-natural-language attributes.
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