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

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

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

From: Herriot, Robert (Robert.Herriot@pahv.xerox.com)
Date: Fri Oct 27 2000 - 16:53:04 EDT

  • Next message: Carl Kugler/Boulder/IBM: "Re: IPP> IPP Bake-Off 3 Issue 6"

    I would suggest that you need more latitude with allowed URLs.

    With my proposal, the Printer can certainly allow different users and
    passwords with the same URL. However, for a specific URL, the Printer cannot
    issue an authentication challenge to a Set-Printer-Attributes operation and
    not issue an authentication challenge for Print-Job operation. Rather, the
    Printer would have two URLs for the same printer (see the multivalued
    "printer-uri-supported" attribute): one that issues a challenge and one that
    doesn't. The one that issues a challenge would support
    Set-Printer-Attributes and the one that doesn't wouldn't support
    Set-Printer-Attributes.

    Bob Herriot

    > -----Original Message-----
    > From: Adams, Charles A [mailto:charles.a.adams@opbu.xerox.com]
    > Sent: Thursday, October 26, 2000 1:29 PM
    > To: IPP Discussion List (E-mail)
    > Subject: RE: IPP> Reopen IPP Bake-off decision for authentication
    >
    >
    > 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 : Fri Oct 27 2000 - 17:02:57 EDT