> Bill Wagner noted that this issue revolves around the interpretation of
allowable HTTP behavior?and
> perhaps should be out of scope for the IPP WG. Since the group has
already resolved that sending a
> zero-length POST is invalid, he believes that the interoperability issue
should be closed.
I don't believe that we ever reached a consensus on whether authorization
is always on the basis of URI. If we allow authorization on the basis of
IPP operations, then you can't limit this issue to the HTTP layer.
Remember that a request can be rejected at either the HTTP OR IPP layers.
For example a request might be rejected with HTTP 401 (Unauthorized) OR IPP
client-error-not-authenticated (0x0402).
> It was noted that a Validate Job command will successfully generate a
challenge?regardless of how the HTTP security might be implemented.
I doubt that this statement is always true, unless some other conditions
are in place. For printers that authorize on the basis of the request URI,
this is true if the request URI refers to a protected resource. For
printers that authorize on the basis of the IPP operation (or operation AND
URI), this won't work unless the spec guarantees that Validate-Job MUST be
authorized identically to Print-Job. Without such a requirement in the
spec, it's not obvious to me that Validate-Job would be authorzed
identically to Print-Job, since Validate-Job, unlike Print-Job, consumes
virtually no resources. Also, for Digest, since the "nonce" value in the
challenge may be good for only one request, the spec would have to
guarantee that the response to a Validate-Job challenge will authorize a
Print-Job request.
-Carl