See my comments below, marked RT2>
I am using this iresponse to respond to both
Roger's and Carl-Uno's comments.
Randy
> -----Original Message-----
> From: Carl-Uno Manros [SMTP:carl at manros.com]
> Sent: Wednesday, January 07, 1998 7:02 AM
> To: Roger K Debry; ipp at pwg.org> Subject: Re: IPP> Additional proposal details
>> 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.
> RT2>You can put HTTPS restrictions in the protocol
RT2>document, but I don't think it belongs in the
RT2>model document. Also with regards to the name
RT2>of the attribute, this is an IPP ATTRIBUTE, so
RT2>the "server" in the "server-redirect-uri" is always
RT2>an IPP server. The IPP protocol itself is opaque
RT2>to whatever transport it runs over. And we've always
RT2>had the idea of IPP clients and servers in the
RT2>documents.
RT2> ..snip..
> >
> >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.
> RT2>I meant that this is a TLS session, and TLS
RT2>sessions are defined by the TLS document.
> >
> ><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.
> RT2>The term redirect does not necessarily mean we
RT2>are redirecting to another host or machine. Its
RT2>none of the clients business to actually know
RT2>which components of a URL we are redirecting.
RT2>The "host" part is only one of a number of URL
RT2>components a server might redirect. URL
RT2>redirection has a "de-facto" definition that has
RT2>been used by the HTTP community, and it is
RT2>this definition I am using. NOTE however I am
RT2>still putting the redirection in the IPP layer, and
RT2>not attempting to overload HTTP redirection,
RT2>which might happen totally independently of
RT2>IPP protocol messages.
RT2>Given this, I don't think we have an attribute
RT2>naming problem.
> 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?
> RT2>It wouldn't matter which URI the server
RT2>returned, in this particular case, because
RT2>using either one gets the same result.
> >
> >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?
> RT2>It depends. I would issue job-information
RT2>requests to the job-uri I used to send the job,
RT2>and not to the containing-printer-uri. But if
RT2>you wanted to submit this request to the
RT2>printer-uri, then you're right it might be an
RT2>optimization for the client to remember the
RT2>secure-URI to which it submitted the job, but
RT2>ultimately whether the client used the redirected
RT2>or "base" URI, the results would be the same,
RT2>because if the client issued the request to the
RT2>"base" URI, it would then be redirected again, and
RT2>it would use the redirected URL. So basically
RT2>you're suggesting a client optimization step
RT2>which is an implementation detail, and something
RT2>we wouldn't have to "standardize" in the documents.
> >
> >----
> >
> >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???
> RT2>Isn't it possible for a client to issue a get-jobs
RT2>operation to a printer-uri, and specify which
RT2>job attributes are returned for each job? If
RT2>so, it is possible that one of the requested
RT2>attributes that are returned might be the
RT2>"containing-printer-uri" attribute.
> >
> >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?
> RT2>Bob's proposal ONLY addresses how to
RT2>establish a "secure" connection. Client discovery
RT2>of security-related URIs is only one feature
RT2>that redirection might support.
> >
> >-- 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.
> RT2>I don't know what a "weird" flow is.
> >
> >
> >
> >