This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------ =_NextPart_000_01BD0DA1.7E4CA590
Content-Type: text/plain
Please review the attached details to the
proposal I loosely suggested earlier. This
proposal addresses Bob's concerns with
the problems of printer-uri and printer-tls-uri
handling...
Randy
------ =_NextPart_000_01BD0DA1.7E4CA590
Content-Type: text/plain;
name="redir.txt"
Content-Disposition: attachment;
filename="redir.txt"
TLS Redirection Modifications
The following changes to the model document
would be required in order to support my
earlier redirection proposal. The changes
appear to be simple, and would allow us to
use the term "printer-uri" throughout the
document, without all the "hand waving"
(similar to Bob's proposal).
Section 3.1.3.2 Response Operation Attributes
An additional operation response
attribute would be defined:
server-redirect-uri
This is a generic redirect (not TLS specific)
that allows servers to redirect requests to
another URI. NOTE: The redirect only applies
to each request. A client should not assume
the lifetime of a redirect to last beyond the
particular request that was originally
redirected.
clients MUST recognize and use redirects.
----
For all operations, an additional operation
attribute MAY be included by clients:
client-TLS-requested
This attribute would indicate to the server
that the client wishes to use TLS for the
session.
If the server supports TLS, it would return
the generic redirect response attribute
described above. If the server DOES NOT
support TLS, then the server would return the
"scheme-not-supported" error code to the
client.
----
On a get-printer-attributes request, the
"printer-uri" returned would always be the
URI that was used to issue the get-attributes
request (like Bob's proposal)
On a get-job-attributes request, the
"containing-printer-uri" would be either the
base "printer-uri" (non-TLS), or a
redirected TLS URI that was actually used to
submit the job. I submit that we can leave
this up to implementations since I think the
client results would be the same.
----
On a get-jobs request to a printer-uri, the
"containing-printer-uri" attribute returned
for each job would be implementation-specific.
It would either be the "printer-URI" (non-TLS)
for the printer, or it could be a redirected
TLS URI. This needs to be implementation-specific
so as to allow servers to decide how job-
specific information is displayed for a
particular client.
--
In addition to addressing Bob's concerns
with printer-uri and printer-tls-uri, this
proposal also offers the following
advantages:
-- It allows a TLS-capable server the ability
to only require TLS negotiation for
particular operations that require the server
to allocate resources. For instance, a
server that requires all print jobs to be
authenticated might still want all clients
to be able to get attributes for the printer,
as well as validate job parameters, without
going to the expense of performing TLS
negotiation. It basically allows an
administrator to decide what types of
operations should be authenticated. In the
current spec, ALL operations are authenticated
or NONE are. This is a nice scalability
feature
-- We no longer have to worry about publishing
multiple URI strings in directories or other
places in order to support TLS sessions to
a server. There's only one URI for the
printer. If a client attempts an operation to
the printer URI, and the server deems that
authentication is required, then it
automatically issues a redirect, similar to
the way current web browsers bounce back and
forth from SSL and non-SSL connections to a
a particular web "service".
------ =_NextPart_000_01BD0DA1.7E4CA590--