IPP Mail Archive: IPP> IIG - BakeOff3 Issues still remaining

IPP Mail Archive: IPP> IIG - BakeOff3 Issues still remaining

IPP> IIG - BakeOff3 Issues still remaining

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Sat Mar 03 2001 - 14:27:40 EST

  • Next message: McDonald, Ira: "IPP> RFC 3080/3081 - BEEP (Blocks Extensible Exchange Protocol)"

    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)
       3. Carl Kugler email on issue 3.2 (which has been split into 3.2 and new

    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.


    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

                    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

    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