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).
To avoid a challenge on a Cancel-Job following a job creation operation,
Bob's scheme of hierarchical URLs would work IFF "job-uri" is structured
such that the previously authenticated "printer-uri" is a prefix of the
"job-uri". But we haven't had this kind of structure in "job-uri" before,
and in fact I thought we allowed for things like jobs silently routed to
other printers with unrelated "printer-uri".
Authorization for Set-Attributes operations is another case to consider,
but in this case we could probably leave it up to the Printer whether it
wants to challenge based on URI or IPP operation.
-Carl
---------------------- Forwarded by Carl Kugler/Boulder/IBM on 11/01/2000
01:13 PM ---------------------------
From: Carl Kugler on 11/01/2000 09:27 AM
To: ipp at pwg.org
cc:
From: Carl Kugler/Boulder/IBM at IBMUS
Subject: Re: IPP> IPP Bake Off 3 Issue 2
"Taylor, Ross E" <ross.e.taylor at o...> wrote:
> This requires that the user set up the client with multiple URL's for
> different types of requests. It also means that the URL cannot be shared
> between IPP and the printer web pages. Currently, one of the most
> attractive things about IPP is that it can be set up on a PC by simply
> putting the URL for the printer into the Add Printer Wizard. If the URL
has
> to be a different URL from the printer's home page URL, and there need to
be
> different URL's for different types of requests, the process is much more
> complicated for the user. The extra effort gains nothing for the user.
I agree with Ross. A "protection space" is defined by the "realm value",
in combination with the *canonical root URL* of the server being accessed.
-Carl