Subject: IPP> Additional proposal details

From: "Turner, Randy" <[email-masked]>
Date: Sat, 20 Dec 1997 23:46:28 -0800

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

---

From: Tom Hastings <[email-masked]>
Date: Tue, 6 Jan 1998 18:00:57 PST

Randy,

I have a few questions on your proposal to use an IPP redirect mechanism.  
But it does seem to be simple and allows scalability where a print job could 
be performed on a different server than to which it was originally 
submitted.  This was a feature that Kinko's liked.

Also, as you point out, it allows an implementor and/or system administrator 
to decide on an operation by operation basis, which operations needs
more security and which do not.

The key is that all clients MUST support the redirect mechanism.

I'm trying to compare your scheme with Carl-Uno and Larry's
of having a single multi-valued "printer-uri-supported" Printer attribute
and a single-valued  "printer-uri" operation attribute.  The directory
entry would also be the multi-valued "printer-uri-supported" attribute.

Both schemes simplify our current document and have a single attribute.

See comments marked TH> below on your proposal.

Tom

Here is your attachment as text:

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.

TH> Presumably, this "server-redirect-uri" Operation attribute is
TH> MANDATORY for a Printer to support, but is only returned on
TH> a redirect response, correct?

TH> Also we need to add a redirect status code in section 13.1.3
TH> Redirection Status Codes, say, "server-redirect", correct?

clients MUST recognize and use redirects.

----

For all operations, an additional operation
attribute MAY be included by clients:

client-TLS-requested

TH> Presumably, a 'boolean' attribute, correct?
TH> How about making the value of this attribute specifying what
TH> security is requested, perhaps as a keyword value? 
TH> Something like "client-security-requested" with values: 'tls' and
TH> 'digest'.

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.

TH> Presumably the server rejects the request as well, correct?
TH> Also this attribute is MANDATORY for a server to support,
TH> but which values depends on implementation.

----

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

TH> This is a good feature.  However, if a client wants security and
TH> only has an HTTP URL, how does it get started?  It certainly doesn't
TH> want to do a Print-Job and send valuable data, before gettting the
TH> TLS URL.  So this means that the client that wants security is forced
TH> to do a Validate-Job with the HTTP://... URL in order to get back
TH> the redirect HTTPS://... URL, correct?

TH> After getting back the HTTPS:// URL, the client can either do another
TH> Validate-Job operation to validate the attributes before wasting time
TH> sending the data, or it can do the Print-Job operation and send the
TH> data and risk wasting the time sending the data for a job that is
TH> rejected.

TH> Presumably, before doing the second validate or Print-Job, the
TH> client and server perform the TLS handshake.

TH> Presumably, the TLS handshake doesn't have to be repeated for the
TH> Print-Job, after the second Validate-Job, correct?  In other words,
TH> the TLS handshake is for the session, not for each operation?
TH> Only after a redirect, does the client have to repeat the TLS
TH> handshake, correct?

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

At 23:46 12/20/1997 PST, Turner, Randy wrote:
>Attachment Converted: "C:\WINNT\Profiles\hastings\Personal\Attach\redir.txt"
>

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 6 Jan 1998 22:53:16 -0800

See my response to your comments below.

My comments are marked RT>

R.

> -----Original Message-----
> From:	Tom Hastings [SMTP:[email-masked]]
> Sent:	Tuesday, January 06, 1998 6:01 PM
> To:	Turner, Randy; [email-masked]'
> Subject:	Re: IPP> Additional proposal details
> 
> Randy,
> 
	RT> Yes.

> TH> Redirection Status Codes, say, "server-redirect", correct?
	RT>I think we need an indication (like a status code) so
	RT>that the client knows that it received a redirect. If we
	RT>don't have a status code, then the operation response
	RT>attributes would have to be examined on every response
	RT>to see if the original request was redirected. Having a
	RT>status code like you suggested is better and more 
	RT>efficient since we're already paying the price of having
	RT>to check the status code on all responses.
> TH> Something like "client-security-requested" with values: 'tls' and
	RT>I really wouldn't like to preclude other security mechanisms
	RT>to be used in future IPP revisions, but I would like to nail
	RT>down TLS for version 1.0. I intended this operation attribute
	RT>to be a BOOLEAN so that (for IPP version 1.0) I'm putting a
	RT>stick in the mud with regards to interoperable security.
	RT>Having said that, we might want to say that this is an 
	RT>enumeration, and that for version 1.0 we are only defining
	RT>(mandating) that this must be set to the value of "enum-tls"
	RT>or whatever. This would save us the hassle of having to
	RT>deal with the boolean for legacy IPP 1.0 implementations 
	RT>in the future. Because if we allow more than one security
	RT>mechanism to be specified, then we would have to add
	RT>another attribute that was an enum; meaning we would
	RT>have to support both the boolean for legacy IPP, AND the
	RT>new enum. If we start out with this operation attribute as
	RT>an enum and mandate that for 1.0 it only has one value,
	RT>then we can add other possible enum values to this 
	RT>attribute for later revisions of the protocol, and we don't
	RT>have the "legacy" IF statements in our code for both old
	RT>and new operation attributes. comments?

> TH> but which values depends on implementation.
	RT>All of the attributes and associated status codes would
	RT>be mandatory to support for both servers and clients.
	RT>However, certain schemed URIs that are returned in a
	RT>redirect response may not be supported by all clients.
	RT>(unless its an HTTPS-schemed URI, then it must be
	RT>supported).
> specific information is displayed for a 
	RT>You'll note that most of the scalability and flexibility of
	RT>this proposal mostly applies to IPP servers and subsequently
	RT>server administration framework. If a CLIENT wants a
particular
	RT>operation to be "secure" , then it includes the 
	RT>"client-security-requested" operation attribute with whatever
	RT>operation it is attempting.

> TH> data and risk wasting the time sending the data for a job that is
	RT>This is basically true, but we don't really define what the
client
	RT>does, you've just outlined some potential client policies but
we
	RT>don't "standardize" the clients behavior with regards to the
	RT>order of operations. We can suggest, but I don't think we
need
	RT>to mandate.

> TH> client and server perform the TLS handshake.
	RT>When the client requested security using the 
	RT>"client-security-requested" attribute, the server returned
	RT>a redirect response. In the normal case, the redirected
	RT>URI would be an HTTPS-schemed URI to which the client
	RT>would then re-issue the operation and negotiate security.

> TH> Only after a redirect, does the client have to repeat the TLS
	RT>This is correct, TLS handshakes are expensive and the
	RT>successful TLS-handshake negotiated session can be used 
	RT>for as many operations as the server decides it allows before
	RT>a new handshake is required. This isn't my specification, its
	RT>defined in detail in the TLS 1.0 specification.

> >Attachment Converted:
> "C:\WINNT\Profiles\hastings\Personal\Attach\redir.txt"
> >

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 07 Jan 1998 06:35:30 -0800

>My comments are marked RT>

Randy, I have not copied your while message, only one comment from you, 
where I think you are breaking the security.

Carl-Uno

>	RT>operation it is attempting.

CM> If you try this with a job submission operation, you have already sent 
CM> your MIME type application/ipp, which means that all your data were sent 
CM> unencrypted before you got the secure URI back, so your feature does
CM> not make any sense in combination with certain operations. It is not as 
CM> generic as you describe it above. Instead you might actually mislead
CM> a user to think that their transmission is secure, when in reality
CM> it is not.

---

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 07 Jan 1998 07:01:47 -0800

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 ...
>
><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.
><RKD> Any rules about cascading redirects?
>
><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.
><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.
><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?
>
><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?
>
>----
>
><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???
>
>--
>
><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?
>
><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.
>
>
>
>

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 7 Jan 1998 08:53:58 -0800

A client IPP implementation would never issue a
	"print-job" operation in the clear, and it would know
	that if it is using an "HTTP:" scheme that thats what
	is happening. An HTTP client wanting to use security
	for the connection would never use "print-job". It would
	always use "create-job" with a 
	"client-security-requested" attribute. It would then
	send issue "send-data" ops , etc..

	This is because its possible for redirection ot occur with
	any operation, and a client would want to make sure that
	a TLS-session is in progress to a particular IPP server
	before sending any sensitive data. Keep in mind that this
	is not only possible with IPP redirects, but is possible with
	standard HTTP redirects as well, which is out-of-band to
	actual IPP operations, and our normative scope as well
	(except for the protocol doc).

	By the way, it is possible to issue a "print-job" operation
	within the context of a TLS session. The client would issue
	a "validate-job" with the "client-security-requested" operation
	attribute set, and then use the returned redirect URI to issue
	the "print-job" operation securely.

	Randy

> From:	Carl-Uno Manros [SMTP:[email-masked]]
> Sent:	Wednesday, January 07, 1998 6:36 AM
> To:	Turner, Randy; 'Tom Hastings'
> Cc:	[email-masked]'
> Subject:	RE: IPP> Additional proposal details
>

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 7 Jan 1998 09:30:52 -0800

See my comments below, marked RT2>

I am using this iresponse to respond to both

Roger's and Carl-Uno's comments.

Randy

> Sent:	Wednesday, January 07, 1998 7:02 AM
> To:	Roger K Debry; [email-masked]
	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..

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

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

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

> ><RKD> to take any subsequent actions on this
	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.

> ><RKD> come back telling me what printer it is
	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.

> ><RKD> same printer -- one just being a secure
	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.

> ><RKD> secure conenction, instead of simply looking
	RT2>I don't know what a "weird" flow is.

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 7 Jan 1998 13:19:45 -0800

Yes, the redirection mechanism can be used for these
and other purposes, such as redirecting jobs depending
upon the document format selected, or any other parameters
that describe the job, etc..etc...etc.. in some ways the
inclusion of redirection might be orthogonal to the problem
of trying to select a security URI. 

Randy

> Sent:	Wednesday, January 07, 1998 12:40 PM
> To:	Larry Masinter; Carl-Uno Manros
> Cc:	Turner, Randy
> Gee, I think that Randy's redirection is useful for any type of
> transport
> for the two stated purposes:
> 
> 1. Changing URIs for security
> 2. Handing jobs off to other servers
> 
> Correct?
> 
> Tom
> 
> 
> At 09:38 01/07/1998 PST, Larry Masinter wrote:
> >What do you think of this line of reasoning:
> >
> >Use features of the transport (transport = HTTP, feature =
> redirection)
> >when you're trying to accomplish something
> >that is transport specific. If you were to layer IPP on top of
> >a different transport (Corba IIOP, direct TCP or whatever), would
> >you still need the redirection?
> >
> >Maybe not, so you're probably safe using HTTP redirection to
> >accomplish IPP redirection.
> >
> >Larry
> >-- 
> >http://www.parc.xerox.com/masinter
> >
> >

---

From: Tom Hastings <[email-masked]>
Date: Wed, 7 Jan 1998 11:37:11 PST

A minor quibble: A client should NOT use Create-Job, instead of Print-Job,
when the client wants security, because Create-Job is an OPTIONAL operation,
so that the Printer object might not have implemented it.

As you later suggest the client should use the Validate-Job operation
first, not the Create-Job operation.

Tom