If I understand your second case correctly, you are describing current HTTP
behavior with an additional client feature which keeps a user from
accidentally performing an operation if a challenge is not received.
The problem you are solving is a bit different from the one originally
stated. The original desire was for a printer which would normally not
issue a challenge but which could be asked by a user to issue a challenge
when the user wanted better authentication.
The person who submitted this problem believes that it is important.
I have suggested that if there really is a problem needing a solution, the
simplest solution is for the printer to have two URLs one that always issues
a challenge and one that never issues a challenge.
Bob Herriot
> -----Original Message-----
> From: Scott Lawrence [mailto:lawrence at agranat.com]
> Sent: Tuesday, March 30, 1999 1:54 PM
> To: IETF-IPP
> Subject: RE: IPP> MOD - Issue 2 - Challenge
>>>> > I have been pondering about whether we are trying to make life a
> > little too
> > difficult for ourselves when we look for a solution to this
> > issue.
>> I'd say that was nicely understated.
>> > Why don't we mandate in IPP/1.1 that IPP printers ALWAYS
> send a challenge
> > for Digest Authentication?
>> I'm not clear on why this is an issue; as I see it there are
> two cases:
>> - Print Service wants authentication.
> The server has all it needs to enforce that today in the HTTP layer.
>> - User wants authentication.
> All that the user needs for this is an indication from the
> user agent
> that a particular operation is or is not authenticated, and
> perhaps some
> UI mechanism to indicate that it should not be performed without
> authentication.
>> Note that I said 'Print Service' and 'User', _not_ 'Server'
> and 'Client (or
> User Agent)'. Software doesn't make these decisions, people
> do. Print
> services in some environments will be wide open; anyone who
> can get the
> packets there has a right to print. Others will require
> authentication to
> support accounting or access control. Some users will want
> to know that
> they are properly authenticated, or that the print service is
> authenticated
> (digest is symmetric).
>> If IPP needs anything at all, it needs only a recommendation
> that the User
> have an indication and/or option to require authentication.
> If the service
> doesn't offer it, then the user can find a service that does.
>