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: Carl Kugler/Boulder/IBM (kugler@us.ibm.com)
Date: Wed Nov 01 2000 - 15:48:16 EST

  • Next message: Hastings, Tom N: "IPP> Proposed Resolution to BO Issue 4: requesting unsupported attribu tes in query operations"

    P.S. We discussed a related issue extensively back in Mach and April,
    1999, following BO2, starting at


    and ending at


    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

    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.


    ---------------------- 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@pwg.org
    From: Carl Kugler/Boulder/IBM@IBMUS
    Subject: Re: IPP> IPP Bake Off 3 Issue 2

    "Taylor, Ross E" <ross.e.taylor@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
    > to be a different URL from the printer's home page URL, and there need to
    > 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.


    This archive was generated by hypermail 2b29 : Wed Nov 01 2000 - 15:58:13 EST