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
>