IPP Mail Archive: Re: IPP> IPP Bake Off 3 Issue 2

IPP Mail Archive: Re: IPP> IPP Bake Off 3 Issue 2

Re: IPP> IPP Bake Off 3 Issue 2

From: Atsushi Uchino (uchino@eitc.epson.com)
Date: Fri Nov 03 2000 - 14:00:14 EST

  • Next message: Hastings, Tom N: "IPP> MOD - RFC 2911 .doc and .pdf versions with line numbers down-load ed"

    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.

    Anyway our client can't do anything except open error dialog for user
    when Validate-Job returns error after challenge succeeded.
    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:-(.

    Atsushi



    This archive was generated by hypermail 2b29 : Fri Nov 03 2000 - 17:04:18 EST