Some comments on Roger's comments below.
Carl-Uno
At 09:51 AM 1/7/98 -0500, Roger K Debry wrote:
>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?
CM> I think we could call it printer-....
CM> as this does not apply to job operations (which
CM> would need to use the URI they were originally
CM> given as result of the job submission. We will
CM> need to introduce a rule that if a job
CM> submission used TLS, the JobURI also has to
CM> be from the HTTPS scheme.
>>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?
CM> This only needs to be talked about in the
CM> protocol document, and there a session is
CM> what HTTP defines as a session.
>><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?
CM> We had this in our internal discussion yesterday,
CM> and the more I think about it, the more sense it
CM> makes to have a separate operation for the scheme
CM> switching, initiated by the IPP client.
>>>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!
CM> I think Roger is right again about the terminology,
CM> we are trying to use this for both scheme switching
CM> and redirects, the first one intitated by the client,
CM> the second by the server.
CM> Whatever we do with the redirect, I still support the
CM> idea of having a multi-valued printer-URI attribute
CM> where the right URI scheme can be picked up directly,
CM> as Roger points out.
>>----
>>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.
>>>>