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

Carl Kugler <kugler@us.ibm.com> Tue, 12 May 1998 19:50 UTC

Delivery-Date: Tue, 12 May 1998 15:50:44 -0400
From: Carl Kugler <kugler@us.ibm.com>
To: ipp@pwg.org
Subject: IPP> MOD & PRO - Questions about "printer-uri" or "job-uri"
Message-ID: <5030100020398311000002L012*@MHS>
Date: Tue, 12 May 1998 15:39:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipp@pwg.org
Content-Transfer-Encoding: 8bit

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 the 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-URI, 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 be
absoluteURIs or abs_paths (see
ftp://ietf.org/internet-drafts/draft-fielding-uri-syntax-02.txt for definitions)
? If "printer-uri-supported" is to specify host, scheme, or port, absoluteURIs
are required.  If "printer-uri" or "job-uri" are absoluteURIs, then the HTTP
request-URI and the target Operation Attribute can't be identical.  Which
raises some questions:

- Suppose the "printer-uri" (or "job-uri") and request-URI are not identical?
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 resource
because of:
* An empty abs_path is equivalent to an abs_path of "/".
   * Characters other than those in the "reserved" and "unsafe" sets are
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.  Should 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 form


  Confused implementor in Boulder,

    Carl Kugler

IPP> MOD & PRO - Questions about "printer-uri" or… Carl Kugler