Roger,
According to my reading of the RFC's, both basic authentication and
digest pass along a user name, but neither passes the client's host.
However, digest has the concept of realm which is the context of the
user name, and that is essentially the purpose of host name in LPD.
But I still stand by my original comment which stated that the security
document does not address the issue of supporting job-originating-host
or job-originating-user. Perhaps the model needs to abandon
job-originating-host and replace it by 'realm'.
In any case, the security document needs to state how to support the
job security attributes, such as job-originating-user, for each
security solution. Otherwise, we don't have interoperability.
Bob Herriot
> From rdebry at us.ibm.com Fri Jul 25 07:09:39 1997
>> Doesn't digest or http basic authentication handle this? It certainly can
> identify the user.
>> Roger K deBry
> Senior Techncial Staff Member
> Architecture and Technology
> IBM Printing Systems
> email: rdebry at us.ibm.com> phone: 1-303-924-4080
>>> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 07/25/97 07:52
> AM ---------------------------
>> ipp-owner @ pwg.org
> 07/24/97 06:08 PM
> Please respond to ipp-owner at pwg.org @ internet
>> To: ipp @ pwg.org @ internet
> cc:
> Subject: IPP>SEC >MOD security and the LPD gateway
>> As I work on the LPD gateway document, I realize, once again, that the
> security documents don't deal with two attributes that we in the model
> have assumed would be handled at the security level. These attributes
> are:
>> o job-originating-user
> o job-originating-host
>> The LPD-to-IPP gateway receives these two values in the control file and
> the IPP-to-LPD gateway needs to put these into the control file.
>> There may be work-arounds for the gateway. But that still leaves
> these two job attributes without any way to set them unless we make
> them explicit parameters in operations or create new HTTP headers.
>> Comments?
>> Bob Herriot
>>>