IPP> Reopen IPP Bake-off decision for authentication

IPP> Reopen IPP Bake-off decision for authentication

IPP> Reopen IPP Bake-off decision for authentication

Herriot, Robert Robert.Herriot at pahv.xerox.com
Fri Oct 27 16:53:04 EDT 2000


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



More information about the Ipp mailing list