IPP Mail Archive: RE: IPP> Reopen IPP Bake-off decision for

RE: IPP> Reopen IPP Bake-off decision for authentication

From: Adams, Charles A (charles.a.adams@opbu.xerox.com)
Date: Thu Oct 26 2000 - 16:28:31 EDT

  • Next message: McDonald, Ira: "RE: IPP> IPP Bake-Off 3 Issue 5"

    Folks,

            Hi everyone. This is just one opinion from Xerox for your
    consideration.

    Chuck Adams
    Office Printing Business
    Xerox Corporation

    ----
    

    From: Taylor, Ross E Sent: Thursday, October 26, 2000 8:50 AM To: Adams, Charles A; Glass, Brian R Subject: RE: IPP> Reopen IPP Bake-off decision for authentication

    This is a bad decision from our standpoint, and I think for IPP as a whole. Since we have one IPP URL, "/", this does not allow us to ever authenticate different requests differently. There cannot be a different password for administrators and users, based on the type of IPP request. We also use "/" for CentreWare IS, so authentication would have to be turned on for IPP and for CentreWare IS at the same time, using the same username and password. This would effectively require administrator access in order to print over IPP.

    The alternative is to require special URL's for printing and/or disallow IPP printing over port 80, all of which makes it harder for the user to set it up.

    Since an empty request for IPP is asking for nothing, it seems reasonable that no authentication is required. I am not sure whether we actually have a problem with this, since the client that was using this method was having other problems with us and eventually worked.

    ---------------------------------------------------------------------------- Ross Taylor | "Gods manifest themselves in many forms, Ross.E.Taylor@opbu.xerox.com | Bring many matters to surprising ends; (503) 685-3586 | The things we thought would happen Xerox, Inc. | do not happen..." The Bacchae, Euripides ---------------------------------------------------------------------------- This message does not necessarily represent the opinion of Xerox, Inc.

    -----Original Message----- From: Adams, Charles A Sent: Thursday, October 26, 2000 8:18 AM To: Taylor, Ross E; Glass, Brian R Subject: FW: IPP> Reopen IPP Bake-off decision for authentication

    Is this proposal OK with us?

    Chuck Adams

    -----Original Message----- From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.COM] Sent: Wednesday, October 25, 2000 5:22 PM To: IPP Discussion List (E-mail) Subject: IPP> Reopen IPP Bake-off decision for authentication

    At the recent IPP bake off the following issue came up.

    Some clients determined if a Printer requires authentication by sending an empty HTTP request. Some Printers treated this as an error. The resolution was for clients to send a ValidateJob operation and by inference to allow Printers to reject empty HTTP requests.

    I raised the issue about whether a Printer should perform the authentication challenge based solely on the URL or whether it could react differently to an empty request than to a Validate-Job request.

    I asked an HTTP expert and received the following information.

    1) An HTTP server can have any policy. This means that our decision is allowable.

    2) It is best for a client if it can associate the URL tree with the authentication space.

    This means that our decision could be better. That is, we should require an IPP Printer to decide whether to issue an authentication challenge by examining the URL and nothing else, e.g. a Printer receiving a request for a particular URL, gives the same challenge to an empty request as to a Validate-Job request.

    This solution allows a client to use Validate-Job to request a challenge as we decided to allow. It also allows a client to use the empty request.

    The important difference between our decision and what I am proposing is that the Printer must perform an authentication challenge consistently for a URL regardless of the contents of the message body. This rule make IPP behavior consistent with good HTTP policy.

    Bob Herriot



    This archive was generated by hypermail 2b29 : Thu Oct 26 2000 - 16:59:02 EDT