I suggest adding Bob's comments in answer to Randy's comment on case f
as a Note in Section 8.3. Randy said that case f would take a lot
explanation. I think that Bob's explanation as a note is just the
explanation that is needed.
Tom
At 12:52 12/17/1997 PST, Robert Herriot wrote:
>>> From rturner at sharplabs.com Wed Dec 17 00:38:33 1997
>>>> See my comments on the new proposed
>> text below...
>>>> Randy
>>>>>> Robert Herriot wrote:
>>
snip...
>> >
>> > f) the authentication mechanism specifies a user which is
special and
>> > means that the value of the requesting-user-name, which must be
>> > present, is treated as the authenticated name.
>>>> I do not think scenario (f) should be included
>> in this list. It sounds like a real niche
>> case that might take alot of text to explain
>> why this is needed.
>>Case f) is intended for a tightly coupled gateway and server to work
>together so that the "user" name is that of the gateway's client and
>not that of the gateway. Because most if not all system vendors will
>initially implement IPP via a gateway into their existing print system,
>this mechansism is necessary unless the authentication mechanism allows
>a gateway (client) to act on behalf of some other client.
So I suggest adding Bob's explanation as a note as part of case f (changing
"is" to "is able to be":
Note: Case f) is intended for a tightly coupled gateway and
server to work together so that the "user" name is able to be
that of the gateway's client and not that of the gateway.
Because most, if not all, system vendors will initially
implement IPP via a gateway into their existing print system,
this mechansism is necessary unless the authentication mechanism
allows a gateway (client) to act on behalf of some other client.