After discussing the four approaches of handling the two URIs:
1. Current Model document:
"printer-uri" and "printer-tls-uri" operation and printer/directory attribute
2. Bob Herriot's alternate URI scheme:
"printer-uri" operation and printer/directory attribute and
"printer-alt-uri" printer/directory attribute
3. Randy's: redirect mechanism:
"printer-uri" operation and printer/directory attribute
4. Carl-Uno's multi-valued printer-uri-supported scheme:
"printer-uri" operation attribute and "printer-uri-supported" (multi-valued)
printer/directory attribute
its time to write down the client scenario for using these schemes.
I'll start with Randy's.
Also based on recent e-mail, its not clear that a client can know whether
the scheme is different for TLS vs. non-TLS. But this isn't a problem, and
makes the client's life easier, not harder, as it turns out.
Also we are not sure whether an IPP Printer can support both TLS and
non-TLS on the same URI or not.
If the client wants security to submit a print job:
1. The client assumes that the URI that it has supports TLS, and the client
begins with a TLS handshake for a Print-Job operation.
The following responses could occur:
A. The IPP Printer doesn't support TLS, and rejects the TLS handshake
(before the Print-Job is even executed). In this case, the client:
tries the same URI without the TLS handshake, supplies Randy's new
client-tls-requested" operation attribute, but uses a Validate-Job,
instead of a Print-Job, since the client doesn't want to expose unencrypted
data before the Printer has been authenticated to the client and the
following responses could occur:
a. The IPP Printer doesn't support TLS, and rejects the Validate-Job
with the 'client-error-attributes-or-values-not-supported' error having
copied the "client-tls-requested" attribute to the Unsupported Attributes
group in the response.
b. The IPP Printer supports TLS, but on a different URI, so the
IPP Printer rejects the Validate-Job operation and returns Randy's
new redirect status code and the new "server-redirect-uri" operation
attribute. The client now goes back to step 1 above using the new
URI and the Print-Job operation.
B. The IPP Printer supports TLS, but this user is NOT authorized, so the
IPP Printer rejects the TLS handshake.
C. The IPP Printer suupports TLS, the client is authenticated, but
the client supplied "ipp-attribute-fidelity" = 'true' and at least one
supported attribute value, so the IPP Printer rejects the operation.
D. The IPP Printer supports TLS, the client is authorized, client-supplied
attributes pass validation, and the IPP Printer object accepts the
encrypted data.
NOTE: the only reason that the client might assume TLS and send a
Validate-Job operation, instead of a Print-Job operation, is if the
client is supplying the "ipp-attributes-fidelity" explicitly with a 'true'
value and the clent likes to avoid sending (a large amount of) data that
might be rejected because of an unsupported attribute value, thereby
keeping the user waiting for a response that is eventally rejected.
E. For any subsequent operations on the same session, such as
Get-Job-Attributes (using the Printer URI and job-id attribute), the client
need
not repeat the TLS handshake, which is expensive as Randy points out.
This scheme needs only a single "printer-uri" operation attribute and
a single single-valued "printer-uri" Printer and directory attribute.
Tom