IPP> Additional proposal details

IPP> Additional proposal details

Roger K Debry rdebry at us.ibm.com
Wed Jan 7 09:51:52 EST 1998


Comment on Randy's proposal ...


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


<RKD> We've not introduced a formal server
<RKD> object up to this point. It seems that
<RKD> using this naming convention now
<RKD> requires us to say something about a
<RKD> server, although it may not be an IPP
<RKD> object. Is this construed to be a print
<RKD> server, a connection server, a web server?


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.


<RKD> Any rules about cascading redirects?


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.


<RKD> What is a session? Do we need to
<RKD> define it in IPP terms?


<RKD> Why not define a new operation, called
<RKD> Request-TLS-Connection? This would seem
<RKD> much cleaner than allowing the client-TLS
<RKD> requested operation attribute in every
<RKD> existing operation. It sems that the latter
<RKD> requires a lot of "programming hints" to
<RKD> make it work efficiently. For example, you
<RKD> would never send a print-job with real data
<RKD> with a client-TLS-requested attribute,
<RKD> would you?




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.


<RKD> The term "redirect" doesn't seem quite
<RKD> right here. I haven't really re-directed
<RKD> the request someplace else, as occurs in
<RKD> HTTP. I've simply responded with an address
<RKD> to be used when the client wants a TLS
<RKD> session. In effect, it seems I've done
<RKD> nothing more than made it difficult for the
<RKD> client to retrieve the "printer-tls-uri"
<RKD> attribute that could have been in the
<RKD> directory to start with!


----


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)


<RKD> Which URI would you expect the user to
<RKD> issue on a get-print-attributes request?
<RKD> The redirected one, or the original one?
<RKD> Would the responses be different?


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.


<RKD> It seems to me that the semantics are
<RKD> different though. If I return a re-
<RKD> directed TLS URI, Aren't I saying to you
<RKD> that you must use this secure connection
<RKD> to take any subsequent actions on this
<RKD> job?


----


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.


<RKD> Sorry, but I'm totally confused here. I
<RKD> guess I missed it when "containing-
<RKD> printer-uri" slipped into the specification.
<RKD> Why do I ask a printer to tell me what jobs
<RKD> are queued on it, and expect every job to
<RKD> come back telling me what printer it is
<RKD> queued on???



--


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


<RKD> I guess I don't understand why this proposal
<RKD> does anything better than Bob's. With Bob's
<RKD> proposal why can't I require printer-tls-uri
<RKD> for some operations and allow printer-uri for
<RKD> others, knowing that they both apply to the
<RKD> same printer -- one just being a secure
<RKD> connection?


-- 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".


<RKD> See my previous comment. It appears to me
<RKD> that all you have done is to force the
<RKD> client to use an operation attribute (and
<RKD> thereby possibly end up with some weird
<RKD> flows) to find out what the URI is for a
<RKD> secure conenction, instead of simply looking
<RKD> in the directory.




=




More information about the Ipp mailing list