One solution would be to decide that "uri-authentication-supported" is
badly misnamed, and that it actually means "minimum authentication
REQUIRED". Any request to a URI with "uri-authentication-supported"
=='none' MAY be challenged, depending on the operation. Any request to a
URI with "uri-authentication-supported"=='basic'|'digest'|'certificate'
MUST be challenged, regardless of the operation (even an empty POST).
-Carl
---------------------- Forwarded by Carl Kugler/Boulder/IBM on 11/06/2000
10:37 AM ---------------------------
From: Carl Kugler on 11/06/2000 10:14 AM
To: uchino at eitc.epson.com
cc: ipp at pwg.org
From: Carl Kugler/Boulder/IBM at IBMUS
Subject: Re: IPP> IPP Bake Off 3 Issue 2 (Document link: Carl Kugler)
uchino at eitc.epson.com wrote:
>>Carl,
>>At 1:48 PM -0700 11/1/00, Carl Kugler/Boulder/IBM wrote:
>>P.S. We discussed a related issue extensively back in Mach and April,
>>1999, following BO2, starting at
>>>>http://www.pwg.org/hypermail/ipp/2143.html>>>>and ending at
>>>>http://www.pwg.org/hypermail/ipp/2281.html>>>>I think this keeps coming up because for digest, the client can't do
>>anything without a specific challenge from the Printer: the client needs
>>the nonce. Some clients find it hard to back up and restart a print job
>>that is being generated and on-the-fly. So the client wants to force a
>>challenge before sending the job. For this common case, the Validate-Job
>>solution seems excellent, as long as we guarantee that a Printer will
>>challenge a Validate-Job just like it would a Print-Job (or Print-URI or
>>Create-Job).
>>My intention is that just HTTP challenge packet without IPP contents is
>easer for client if printer can accept a challenge packet which
>content_length is zero.
>The client may know whether the URL requires authentication by admin,
>user, or response from IPP GetPrinterAttributes operation. In such case
>the client can send just challenge packet without IPP contents.
>This approach implies an authorization model based on objects. Some people
insist on authorization by operation instead (or in combination: user X is
authorized to perform operation Y on object Z). (A workaround proposed by
Ira would use "request objects". Apparently that's what they do in SNMP.)
It's impossible to determine the IPP operation without IPP contents (unless
the operation is somehow encoded in the URI.)
>Anyway our client can't do anything except open error dialog for user
>when Validate-Job returns error after challenge succeeded.
What else would you do if you could?
>Also it is less than fifty percent that our server(printer) can judge
>whether the job can print or not when Validata-Job is sent:-(.
I don't expect Validate-Job to guarantee whether or not a job can print.
It really only validates the request attributes and. the printer attributes
(such as printer-state) for a job creation operation. Of course, it knows
nothing about the docment content.
-Carl
>>Atsushi
>