That was my reading too. But as more applications use HTTP, it will
become more important that clients identify themselves in the initial
transaction.
I am hoping that HTTP applications send along authentication information.
But I have a feeling that it is a hope and not current reality.
Bob Herriot
> From rdebry at us1.ibm.com Mon Nov 25 15:31:33 1996
> From: rdebry at us1.ibm.com> X400-Originator: rdebry at us1.ibm.com> X400-Recipients: ipp at pwg.org> X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002245423000002]
> X400-Content-Type: P2-1988 (22)
> To: <ipp at pwg.org>
> Subject: IPP> Re: deBry security proposal
> Date: Mon, 25 Nov 1996 07:44:45 -0500
> Sender: ipp-owner at pwg.org> Content-Length: 1228
> X-Lines: 38
>> Classification:
> Prologue:
> Epilogue:
>> I read 1945 as authorization it NOT typically included, but sent only when
> requested by the server. However, I agree that the specification leaves soem
> room for interpretation.
>> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 11/25/96 05:32
> AM ---------------------------
>> ipp-owner @ pwg.org
> 11/23/96 12:31 AM
>>> To: ipp @ pwg.org at internet> cc:
> Subject: Re: deBry security proposal
>>> I would like to know if Authorization is typically included with an HTTP message
> or only if a server requests it. RFC 1945 is unclear on this point.
>> I ask this because I would like one form of security to be where the client (not
> the end-user) automatically sends an attribute at the HTTP level with the user's
> name and ideally the domain name as well.
>> Such values could implement the attributes operation-user-name and
> operation-host-name. This mechanism would allow a lightweight security
> mechanism that would work in cooperative environments where people don't want to
> deal with passwords but also don't want to cancel other people's jobs
> accidentally.
>> I think that this is one case that Roger missed in his enumeration of possible
> security mechanisms.
>> Bob Herriot
>>