IPP Mail Archive: Re: IPP>MOD action item: revised text for requesting-user-name

Re: IPP>MOD action item: revised text for requesting-user-name

Tom Hastings (hastings@cp10.es.xerox.com)
Fri, 19 Dec 1997 09:48:37 PST

Looks good to me.

A few typos indicated. MUST needs to be capitalized a few places.
Also change the name from Get-Attributes to Get-Job-Attributes (I don't
think that we need to add Get-Printer-Attributes to this list, since
restricting
Printer attributes returned in Get-Printer-Attributes wouldn't apply to end
users).

Tom

At 19:32 12/18/1997 PST, Robert Herriot wrote:
>The following wording replaces all of in section 8.6 according to the
>agreement at todays telcon.
>----------------------------------------------
>
>8.6 The "requesting-user-name" Operation Attribute
>
>
>Each operation SHALL specify the user who is performing the operation
>in both of the following two ways:
>
> 1) via the MANDATORY "requesting-user-name" operation attribute that a
> client SHOULD supply in all operations. The client SHALL obtain the
> value for this attribute from an environmental or network login name
> for the user, rather than allowing the user to supply any value. If the
> client does not supply a value for "requesting-user-name", the printer
> SHALL assume that the client is supplying some anonymous name, such as
> "anonymous".
>
> 2) via an authentication mechanism of the underlying transport which
> may be configured to give no authentication information.
>
>There are six cases to consider:
>
> a) the authentication mechanism gives no information, and the client
> doesn't specify "requesting-user-name".
>
> b) the authentication mechanism gives no information, but the client
> specifies "requesting-user-name".
>
> c) the authentication mechanism specifies a user which has no human
> readable representation, and the client doesn't specify
> "requesting-user-name".
>
> d) the authentication mechanism specifies a user which has no human
> readable representation, but the client specifies
> "requesting-user-name".
>
> e) the authentication mechanism specifies a user which has a human
> readable representation. The Printer object ignores the
> "requesting-user-name".
>
> f) the authentication mechanism specifies a user who is trusted and
> whose name means that the value of the "requesting-user-name", which
> must be present, is treated as the authenticated name.
TH> MUST

>
>The user-name has two forms:
>
> one that is human readable: it is held in the MANDATORY
> "job-originating-user-name" Job Description attribute which is set
> during the job creation operations. It is used for presentation only,
> such as returning in queries or printing on start sheets
>
> one for authorization: it is held in an undefined (by IPP) Job object
> attribute which is set by the job creation operation. It is used to
> authorize other operations, such as Send-Document, Send-URI,
> Cancel-Job, to determine the user when the my-jobs' attribute is
> specified with Get-Jobs, and to limit what attributes to return with
> Get-Attributes and Get-Jobs.
TH> Change to Get-Job-Attributes

>
>The human readable user name:
>
> is the value of the "requesting-user-name" for cases b, d and f.
>
> comes from the authentication mechanism for case e
>
> is some anonymous name, such as "anonymous" for cases a and c.
>
>The user name used for authorization:
>
> is the value of the "requesting-user-name" for cases b and f.
>
> comes from the authentication mechanism for cases c, d and e
>
> is some anonymous name, such as "anonymous" for case a.
>
>The essence of these rules for resolving conflicting sources of
>user-names is that a printer implementation is free to pick either
>source as long as it achieves consistent results. That is, if a user
>uses the same path for a series of requests, the requests must all
TH> make MUST

>appear to come from the same user from the standpoint of both the
>human-readable user name and the user name for authorization This rule
TH> need a period: .

>must continue to apply even if a request could be authenticated by two
TH> make MUST

>or more mechanisms. It doesn't matter which the several authentication
>mechanism a Printer uses as long as it achieves consistent results. If
>a client uses more than one authentication mechanism, it is recommended
>that an administrator make all credentials resolve to the same user and
>user-name as much as possible.
>
>
>
>