Client dosen't care which layer does authentication. Even if it dose
in IPP layer, it seems to be irrelevant for requiring IPP header
for each HTTP packet.
I'd like to propose:
Proposed Resolution: The Client may send empty HTTP post for
authentication as challeng request. The IPP Server should accept
an empty HTTP post if the URL requires authentication and issues
a challenge based on the URL of the post.
Atsushi / EPSON
At 6:23 PM -0800 10/30/00, pmoore@peerless.com wrote:
>The authentication is done in the HTTP layer but it is up to the IPP server to
>decide whther or not to authenticate. It can decide (for example) that
>get-job-attributes requires no authentication but that cancel-job does. In fact
>validate-job does not need to force authentication (or does the spec say it must
>- I dont think so). This is why Microsoft added the 'authenticate-me' operation
>after BO2. This IPP operation forces the printer to issue a 401 response.
>
>
>
>
>Atsushi Uchino <uchino@eitc.epson.com> on 10/30/2000 06:05:35 PM
>
>To: "Zehler, Peter" <Peter.Zehler@usa.xerox.com>, "IPP Discussion List
> (E-mail)" <IPP@pwg.org>
>cc: (bcc: Paul Moore/AUCO/US)
>
>Subject: Re: IPP> IPP Bake Off 3 Issue 2
>
>
>
>Peter,
>
>It strange for me because If IPP server accept empty HTTP request,
>why client has to send Validate-Job Request.
>I think authentication is done by URL. Clinet send HTTP requst to make
>sure whether the URL requires authentication or not. Further more, the
>authentication message is in the HTTP header not IPP request.
>Since URL and all authenticate informations are in the HTTP header,
>authentication should be done in the HTTP layer not IPP layer.
>So I supporsed content length zero should be work fine and the
>best way to reduce network traffic. This isn't simple?
>
>Atsushi / EPSON
>
>At 2:41 PM -0400 10/26/00, Zehler, Peter wrote:
> >All,
> >BO3-2: Some IPP Clients issues a zero length HTTP Post. The Client assumed
> >that this would force a challenge if security is enabled on the Printer.
> >The Client would have a problem if a subsequent print operation were
> >challenged.
> > Proposed Resolution: 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.
> > Action Item: Bob Herriot: Some clients determined if a
> >Printer requires authentication by sending an
> > empty HTTP request. Some Printers treated this as an error.
> >The resolution
> > was for clients to send a ValidateJob operation and by
> >inference to allow
> > Printers to reject empty HTTP requests.
> >
> > 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 our decision 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.
> >
> >
> > Peter Zehler
> > XEROX
> > Xerox Architecture Center
> > Email: Peter.Zehler@usa.xerox.com
> > Voice: (716) 265-8755
> > FAX: (716) 265-8792
> > US Mail: Peter Zehler
> > Xerox Corp.
> > 800 Phillips Rd.
> > M/S 139-05A
> > Webster NY, 14580-9701
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 18:55:25 EST