On the agenda for next week's IPP WG meeting we have:
D. Issue resolution from the October 17-20 bake-off in Boston
2. "IPP Bake Off Issue Resolution" (T. Hastings for P. Zehler)
ftp://ftp.pwg.org/pub/pwg/ipp/issues/Issues-raised-at-bake-off3-010302.pdf
3. Carl Kugler email on issue 3.2 (which has been split into 3.2 and new
3.9)
ftp://ftp.pwg.org/pub/pwg/ipp/new_IIG/IPP-IIG-HTTP-100-Continue-suggestion.t
xt
Issue 3.2 about empty HTTP Post to force a challenge has been closed and the
issue about when a Printer MUST/MAY challenge has been made Issue 3.9.
Carl's suggested solution includes how the client can force the Printer to
issue the challenge.
Please send comments to the mailing list.
Thanks,
Tom
9. Issue 3.9: When MUST/MAY a Printer issue a challenge? - OPEN
When MUST a Printer issue a challenge? When MAY a Printer
issue a challenge?
Proposed Resolutions:
There are two competing resolutions.
Resolution 1 is that a challenge should be issued whenever
an HTTP operation is received on a particular URL. (assuming the URL is part
of an authentication space) The client must accept and respond to a
challenge the first time a URL is accessed.
Resolution 2 allows the vendor to determine when a challenge
is issued. The vendor is free to use the contents of the HTTP request to
determine if the operation mandates a challenge. The client must accept and
respond to a challenge at any time.
The Client should use the IPP operation "validate-job" to
check if a job will be accepted. This operation will cause the Printer to
issue a challenge and check the print request before sending the data. The
IPP Client should also be able to handle a challenge when issuing an IPP
operation since there is no guarantee the connection has not been torn down.
Furthermore, a Printer should accept an empty HTTP post and
issue a challenge based on the URL of the post.
Proposed Resolution 1:
From Bob Herriot:
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 resolution 2 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.
Proposed Resolution 2:
From Peter Zehler:
Allowing IPP Printers to use the contents of an IPP request
to determine if a challenge should be issued allows for increased usability.
The client does not have to keep track of multiple instances of the same
printer and select the appropriate one based on the operation to be
performed. The printer is free to determine when authentication is
required. This allows the client to use a single URL and authenticate
himself when the printer places restrictions on operations or features.
This resolution does not prohibit challenges based
statically on a URL. Resolution 2 does require a client to be ready at any
time to receive a challenge. This should be done anyway since the client
application may be unaware that an HTTP connection has dropped after
authenticating the connection, resulting in a new challenge. Some HTTP
servers have security realms that apply only to a transaction as well as
being connection based.
This archive was generated by hypermail 2b29 : Sat Mar 03 2001 - 14:29:01 EST