IPP Mail Archive: IPP> MOD & PRO - Questions about "printer-uri" or "job-uri"

IPP Mail Archive: IPP> MOD & PRO - Questions about "printer-uri" or "job-uri"

IPP> MOD & PRO - Questions about "printer-uri" or "job-uri"

Carl Kugler (kugler@us.ibm.com)
Tue, 12 May 1998 15:39:22 -0400

The following statement from the PRO doc. seems to imply that the same =
target
printer-uri is placed in the "printer-uri" operation attribute and the =
HTTP
request-URI:

* "printer-uri": When the target is a printer and the transport is HTTP=
or
HTTP (for TLS), the target printer-uri defined in each operation in th=
e IPP
model document SHALL be an operation attribute called "printer-uri" and=
it
SHALL also be specified outside of the operation layer as the request-=
URI on
the Request-Line at the HTTP level. This

Must these URIs be identical?

HTTP/1.1 clients generate an abs_path (a relativeURI) as the Request-UR=
I, which
identifies a resource on a server, but does not include scheme, host or=
port.
Are "printer-uri", "printer-uri-supported", and "job-uri" supposed to b=
e
absoluteURIs or abs_paths (see
ftp://ietf.org/internet-drafts/draft-fielding-uri-syntax-02.txt for def=
initions)
? If "printer-uri-supported" is to specify host, scheme, or port, absol=
uteURIs
are required. If "printer-uri" or "job-uri" are absoluteURIs, then the=
HTTP
request-URI and the target Operation Attribute can't be identical. Whi=
ch
raises some questions:

- Suppose the "printer-uri" (or "job-uri") and request-URI are not iden=
tical?
Should the Printer
a) Return an error status? Warning?
b) Allow one to take precedence over the other?

- Suppose even the "abs_path" part of the URIs differs?

- Suppose they're not identical, but effectively point to the same reso=
urce
because of:
* An empty abs_path is equivalent to an abs_path of "/".
* Characters other than those in the "reserved" and "unsafe" sets ar=
e
equivalent to their ""%" HEX HEX" encoding.
* As a result of an HTTP redirect?
- Suppose one copy of the URI has been supplied, but not the other. Sh=
ould the
Printer
a) Reject the request?
b) Return an error status? Warning?
c) Perform the operation?

My preferences would be:
- Make target URI Operation Attribute OPTIONAL when the transport is =
HTTP or
HTTPS.
- request-URI takes precedence over target Operational Attribute when=
the
transport is HTTP or HTTPS.
- "printer-uri" and "job-uri" have abs_path form.
- "printer-uri-supported", "job-printer-uri", etc. have absoluteURI f=
orm

Confused implementor in Boulder,

Carl Kugler
=